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This second edition represents a major revision and 
fiQ extension of the first edition and is necessitated by the 
continuous evolution of the Compatible Time-Sharing System 
(CTSS) over the past two years of operation. As CTSS has 
been improved in reliability and capacity, since the summer 
and fall of 1963, it has been implemented at both the 
Computation Center and Project MAC. Both installations 
operate as a community service, seven days a week, 
twenty-four hours a day with the MAC computer being 
time-shared full time and the Computation Center computer 
being time-shared about half of the time. At present, over 
110 consoles are scattered throughout the MIT campus, at New 
England colleges, and in the homes of several Project MAC 
participants. As a result, the two installations have had 
extensive experience with a broad spectrum of users. 
Therefore, it is no longer a question of the feasibility of 
a time-sharing system, but rather a question of how useful a 
system can be produced. 

During these two years of growth, there have been frequent 
changes of hardware configuration. Over seven different 
varieties of terminals have been attached to the system 
(three are obsolete now) and several different drum and disk 
configurations have been used. Because of the programming 
interface design, most of these changes have been insulated 
from the average system user. Despite the numerous hardware 
^ changes it has become increasingly obvious that the essence 
of a useful time-sharing system lies in the programming, 
i.e., in the software, and not in the hardware. 

The programming has grown from a skeletal form of perhaps 
50,000 instructions to an estimated size of between 400,000 
and 1,000,000 words of publ i cl y-ava i 1 abl e system program. 
From the few languages which were first available, the 
system also has evolved to presently contain over a dozen 
languages. Much of this growth in both words and in 
languages is the work of many users rather than of system 
programmers. In fact, it has been a goal to enhance and 
simplify the process of sub-system writing by supplying a 
framework that is highly modular and which encourages 
division of responsibility and initiative. 

Many of the ideas described in this manual were mentioned in 
the first edition but at that time had not been implemented. 
In addition, several key features have been introduced to 
make a more complete system. A brief list of some of these 
features, which are detailed more completely within this 
manual, are: password logic, introduction of more elaborate 
accounting procedures, inter-console message, public files, 
and macro commands. Further details of the system design 
^ and implementation are given in Project MAC Technical Report 
No. 16 by J. Saltzer. A summary of system operational 
experience is given by R. Fano in Project MAC Technical 
Report No. 12 (AD-609-296) and is also published as an 
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article in the January 1965 issue of the IEEE Spectrum. 

Two major features have been introduced into the system 
which deserve special comment. First, the entire secondary 
storage mechanism has been redesigned. This is considered 
to be the most significant and far reaching change because 
it improves the mul t i -programmi ng capability of the system 
and the controlled sharing of files on the part of user. 
The design and implementation of this critical section has 
been led by Robert Daley. 

The second major new feature is the improved message 
coordination with the typewriter terminals. This feature, 
while not obvious to users, has greatly improved the 
organization and operation of the supervisor program. The 
work in this important and critical area has been done by 
Stanley Dunten who also has been instrumental in maintaining 
effective system operation. 

The present manual is considered a part of the system 
because it is maintained on-line within the system, and it 
represents an attempt to keep all system documentation 
continuously up to date. As system users know, 
documentation difficulties have been severe, with over 80 
bulletins and numerous research memoranda prepared and 
circulated as amendments to the first edition of the manual. 

The effect of the present manual is that an active system 
user can keep his manual updated. To do this, he should 
periodically inspect a special table of contents of the 
manual, which is maintained on-line within the system in 
reverse chronological order of changes that have been made 
to the various sections. From this special table of 
contents, he can quickly determine which sections have been 
revised since the last time he updated his copy, and then 
obtain on-line printouts of those sections he needs. 
Needless to say, the procedures of requesting appropriate 
sections by mail or in person \f/i11 still be available. In 
any case, the need for maintaining a massive mailing list 
for amendments to the manual is eliminated. 

Ac know 1 edgements 

In addition to the previously-mentioned critical work of 
preparing the present system by Robert Daley and Stanley 
Dunten, the system owes its present form to an ever 
increasing number of staff members and contributors. Other 
contributors to the system programming are, alphabetically: 
Janet Allen, Michael Bailey, Robert Creasy, Patricia 
Crisman, Marjorie Daggett, Daniel Edwards, Robert Fenichel, 
Charles Garman, Robert Graham, Jessica Hellwig, Lyndalee 
Korn, Richard Orenstein, Louis Pouzin, Glenda Schroeder and 
Mary Wagner. In addition, contributions of some of the 
commands have been made by Margaret Child, Leola Odland, Don 
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Oppert, and Jerome Saltzer. Many of the subroutine 
write-ups which served as reference documents for the 
present system were prepared by Edith Kliman/ Judith Spall, 
and Susan Springer. 

A great deal of the present system's impact upon users, has 
been because of its reasonably continuous and reliable 
service. To a large extend, this has been due to the great 
zeal and perserverence of the Computation Center's 
operational staff, who have conscientiously dealt with the 
many problems which have arisen. 

We wish to thank the Computation Center and Project MAC 
administration for contributing the proper environment and 
shouldering the many problems which have been generated. 
They have made possible the present system's high level of 
devel opment . 

Thanks are also due to the maintenance personnel of the 
International Business Machines Corporation and of the. New 
England Telephone and Telegraph Company for their diligent 
efforts in maintaining a high level of system performance. 

A special acknowledgement goes to the Advance Research 
Projects Agency of the Department of Defense, and the Office 
of Naval Research, the sponsors of Project MAC, and the 
National Science Foundation, for the support of some of the 
special equipment at the Computation Center. 

F.J. Corbato 
May 1965 

Cambridge, Massachusetts 
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This handbook is an attempt to document the techniques of 
using a current version (model 13) of the compatible 
t i me- sha r i ng-sys tern (CTSS) which has been developed at the 
i MIT Computation Center. It is primarily a manual of how to 

use the system, in contrast to many of the research memos, 
which have been more detailed in their documentation of the 
techniques of implementation. Because CTSS is basically a 
system which will allow an evolutionary development of 
time-sharing while continuing to allow more conventional 
background systems to operate, it is expected that the 
present manual will of necessity be revised many times 
before it reaches a final form. A good deal of the 

difficulty arises from, on the one hand, the rather drastic 
change in user operating techniques which time-sharing 
permits, and on the other hand the immense amount of 
programming required to fully implement the system. 


0 



The present work, although not highly polished, is being 
presented now to assist in this evolutionary process. It is 
expected to be a supplement to the Computation Center's 
Procedures Handbook which explains many of the general 
administrative details of the Center. Furthermore, a 
knowledge of programming is assumed of the reader. It has 
been our objective to present to an experienced programmer a 
reasonably complete manual which will allow him to use 
wisely the present version of the time-sharing system. 


Because of the rapidity with which many of the features are 
being implemented, and the delays in distributing the 
inevitable revisions, some features are described here which 
are not yet accomplished. The reason for this is that it 
was felt to be important to indicate the intended scope and 
objectives of the system so that individual users could plan 
ahead in their applications. The features which are not 
implemented will be found listed in an appendix which will 
be revised periodically. In addition, each of the chapters 
can be expected to be periodically revised. 


Since the present work is primarily a handbook, no attempt 
has been made to make any comparisons with the several other 
time-sharing and remote-console efforts which are being 
developed by groups else-where. The only other general 

purpose time-sharing system known to be operating presently, 
that of the Bolt, Beranek and Newman Corporation for the 
PDP-1 computer, was recently described by Professor John 
McCarthy at the 1963 Spring Joint Computer Conference. 
Other time-sharing developments are being made at the 
Carnegie Institute of Technology with a G20 computer, at the 
a University of California at Berkeley with a 7090, at the 
V / V® Rand Corporation with Johnniac, and at MIT (by Professor 

Dennis)with a PDP-1. Several systems resemble our own in 
their logical organization; they include the independently 
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developed BBN system for the PDP-1, the recently initiated 
work at IBM (by A. Kinslow) on the 7090 computer, and the 
plans of the System Development Corporation with the Q32 
computer. 

To establish the context of the present work, it is 
informative to trace the development of time-sharing at MIT. 
Shortly after the first paper on time-shared computers, by 
C. Strachey at the June 1959 UNESCO Information Processing 
Conference, H.M. Teager and J. McCarthy at MIT delivered an 
unpublished paper "Time-Shared Program Testing" at the 
August 1959 ACM Meeting. Evolving from this start, much of 
the time-sharing philosophy embodied in the CTSS system has 
been developed in conjunction with an MIT preliminary study 
committee (initiated in 1960), and a subsequent working 
committee. The work of the former committee resulted, in 
April 1961, in an unpublished (but widely circulated) 
internal report. Time-sharing was advocated by J. McCarthy 
in his lecture, given at MIT, contained in "Management and 
the Computer of. the Future" (MIT, 1962). Further study of 
the design and implementation of man-computer interaction 
system is being continued by a recently organized 
institute-wide project under the direction of Professor 
Robert M. Fano, In November 1961 an experimental 
time-sharing system, which was an early version of CTSS, was 
demonstrated at MIT, and in May 1962 a paper describing it 
was delivered at the Spring Joint Computer Conference. 

As might be expected, the detailed design and implementation 
of. the present CTSS system is largely a team effort with the 
major portions of it being prepared by the following: Mrs. 
Majorie M. Daggett, Mr. Robert Daley, Mr. Robert Creasy, 
Mrs. Jessica Hellwig, Mr. Richard Orenstein, and Professor 
F.J. Corbato. Important contributions to some of the 
commands and the background system has been offered by 
Professor Jack Dennis, Mr . J.R. Steinberg, and members of 
the Computation Center Staff. Mrs. Leslie Lowry, Mr. Louis 
Pouzin, and Mrs. Evelyn Dow have contributed to the 
preparation of the commands. 

Special credit is given to Professor Herbert Teager for the 
design and development of his Flexowriter control subchannel 
which allowed the original experimental version of the 
present system to be developed, tested, and evaluated; only 
with. such an opportunity was it possible to have the 
confidence to make the present pilot development of the CTSS 
system. 

We should also like to extend our thanks to the Computer 
Center of the University of Michigan where Professor Bernard 
Caller , Mr. Bruce Arden, and Mr. Robert Graham have been 
very helpful in advising us on the use of their Mad Compiler 
in our time-sharing system. In addition, Mr. Robert Rosin 
kindly made available the Madtran editing program for 
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processing Fortran II subprograms to Mad subprograms. 

We should further like to take this occasion to acknowledge 
partial support by the National Science Foundation, the 
Office of Naval Research, and the Ford Foundation, of the 
development of our present system. We also add our 
appreciation for the support provided the Computation Center 
by the IBM Corporation. 

Finally, we should like to encourage the readers of this 
handbook to examine the present system with a view toward 
improvements and we shall welcome such criticisms. 

F.J. Corbato' 
Cambridge, Massachusetts 
May 1963 
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I dent i f i ca t i on 

Introduction to Time-Sharing 


T i me-sha r i ng is an ambiguous term. Some people use this 
term to describe concurrent operation of several parts of a 
single computer. This sort of operation, also called 
multiprogramming, generally is directed toward efficient 
utilization of hardware. 

The time-sharing system described in this manual seeks to 
allow a somewhat different sort of efficiency. Although 
hardware utilization is still considered, the primary goal 
is concurrent, effective utilization of a single computer by 
several users. 


The motivation for time-shared computer usage arises out of 
the slow man-computer interaction rate presently possible 
with the bigger, more advanced computers. This rate has 
changed little (and has become worse in some cases) in the 
last decade of widespread computer use. 



In part, this effect has been due to the fact that, as 
elementary problems become mastered on the computer, more 
complex problems immediately become of interest. As a 
result, larger and more complicated programs are written to 
take advantage of larger and faster computers. This process 
inevitably leads to more programming errors and a longer 
period of time required for debugging. Using current batch 
processing techniques, as is done on most large computers, 
each program bug usually requires several hours to 
eliminate, if not a comp lete day. The only alternative 
available has been for the programmer to attempt to debug 
directly at the computer, a process which is grossly 
wasteful of computer time and hampered seriously by the poor 
console communication usually available. Even if a 
typewriter is available at the console, there are usually 
lacking the sophisticated query and response programs which 
are vi ta 1 1 y .necessary to allow effective interaction. Thus, 
what is desired is drastically to increase the rate of 
interaction between the programmer and the computer without 
large economic loss and also to make each interaction more 
meaningful by extensive and complex system programming to 
assist in the man-computer communication. 



In addition to allowing the development of usable and 
sophisticated debugging techniques, an efficient 
time-sharing system should make feasible a number of 
relatively new computer applications which can be 
implemented only at great cost in a conventional system. Any 
problem requiring a high degree of intermixture of 
computation and communication on a real-time basis should 
readily lend itself to time-sharing techniques. Examples of 
this type of application include: 
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dec i s i on- t ree problems; real-time 
problems (airline reservations/ 

administration, etc.); gaming 

sociological experiments; teaching 
language learning problems; library 
text editing; algebra manipulators; and 


management 
hospi ta 1 
probl ems; 
machines; 
ret r i eva 1 ; 
many more. 


The Compatible Time-Sharing System (CTSS) is a 
general-purpose programming system which allows a new form 
of computer operation to evolve and yet allows most older 
programming systems to continue to be operated. CTSS is 
used from consoles which may be off several varieties, but 
which in essence are electric typewriters. Each console 
user controls the computer (i.e. as seen by him) by issuing 
standard commands, one at a time. The commands allow 
convenient performance of most of the routine programming 
operations such as input, translation, loading, execution, 
stopping, and inspection of programs. This command 
convenience, although it has a fixed format, causes no loss 
of generality since a command can also be used to start an 
arbitrary programming subsystem with its own control 
1 anguage . 


The consoles of CTSS communicate with the "foreground" 
system, by which computation is performed for the active 
console users in variable length bursts, on a rotation 
basis, according to a scheduling algorithm. The 
"background" system is a conventional programming system 
(slightly edited for the time-sharing version) which, at the 
least, operates whenever the "foreground" system is 
inactive, but which may also be scheduled for a greater 
portion of the computer time. The entire operation of the 
computer is under the control of a supervisor program which 
remains permanently in the 32,768 word A-bank of core 
memory. When a user program is scheduled to be run, it is 
brought into the 32768-word B-bank of core memory (unless it 
is already there) from drum or disk memory. 


Not only are the drum and disks used for swapping of active 
user programs, but all console users utilize the disk memory 
for semi -permanent storage of their active program and data 
files. Cards and magnetic tapes still serve in secondary 
roles as long-time and back-up storage devices. 
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General Description and Usage Techniques 

The foreground system is organized around commands, which 
are system programs accessible to all users, and the user's 
private program files. Both types of programs are stored on 
the disk, along with files of data, documentation, etc. For 
convenience, the disk files have titles with name and class 
designators. Files can be entered from consoles or cards, 
and they may be punched out at disk editing time. 



The Superv i sor 

The supervisor program remains in A-core at all times when 
CTSS is in operation. Its functions include: handling of 
all input and output; scheduling; handling of temporary 
storage and recovery of programs during the scheduled 
swapping; monitoring input and output performed by the 
background system; and performing the general role of 
monitor for all jobs. These tasks can by carried out by 
virtue of the supervisor's direct control of all trap 
interrupts, the most crucial of which is the one associated 
with the interval timer clock. 



The interval timer clock is set for small bursts of time, 
currently 200ms. Every clock burst allows the supervisor to 
interrupt the program currently running in B-core in order 
to interpret input from the consoles or to issue output to 
the consoles. If the input from a console is other than a 
break character, it is left in the supervisor's core 
buffers. When a break character is encountered, the 
supervisor determines whether this is a line of input which 
has arrived early for one of the working programs or whether 
the status of one of the users should be changed i.e., to 
working status or waiting command status. If the line was a 
command line, the user is placed in waiting command status 
so that the next time his turn arrives, the supervisor can 
load the command program as his working core image. 


L 



The user programs are run for periods of time determined by 
the scheduling algorithm. At the end of each program's 
appropriate time or when it changes status, the supervisor 
determines which user is to be run next. It must then 
determine whether the program or programs currently in core 
must be dumped (to disk or drum), in part or entirely, to 
leave room in core for the next user. The next user program 
must then be retrieved from secondary storage together with 
the proper machine conditions. 

In addition to maintaining input and output buffers for each 
user console, the supervisor keeps a record of the status of 
each user. The status of a user may be: "working'', where a 
program is ready to continue running whenever it is next 
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brought in ; "waiting command," where the user has just 
completed a command line at his console; "input-wait" or 
"output-wait," where the program is temporarily held up 
waiting to get a console line in or a free output buffer; 
"file-wait", where the program is temporarily delayed until 
another user has finished using the requested program or 
data file; "FIB-wait", a very specialized status, used only 
by the FIB monitor where there is no FIB job waiting to be 
run; "dormant," where the program has stopped running and 
returned control to the supervisor, but machine conditions 
and the status of memory are preserved for inspection, 
modification, or re-entry; and "dead," where the program has 
terminated, control has been returned to the supervisor, and 
machine conditions and the status of memory have been 
scrapped. 

It should be noted that command programs are handled in 
exactly the same manner as the user's own programs, with 
respect to status and scheduling. The background system is 
also considered another user; at present it has a different 
place in the scheduling algorithm, with permanently lowest 
priority. In addition there is another type of background, 
consisting of background jobs initiated from consoles but 
left to run without console interaction; these jobs are run 
with exactly the same type of scheduling as normal 
foreground programs. 

Command Format 


Commands may be typed by dead or dormant users; they are 
interpreted by the time-sharing supervisor (not by the user 
programs). They can thus be initiated at any time, 
regardless of the particular program in memory. (It is for 
similar reasons of coordination, that the supervisor handles 
all input-output of the foreground system typewriters.) 
Commands are composed of fields separated by blanks; the 
first field is the command name, and the remaining fields 
are parameters pertinent to the command. Each field consists 
of the last 6 characters typed most recently since the last 
blank (initially an implicit 6 blanks). A carriage return 
is the signal which initiates action on the command. 
Whenever a command is received by the supervisor, "W t" is 
typed back. When the command is completed, "R tl + t2" is 
typed back. "W" is the abbreviation for WAIT; "R" for 
READY; "t" is the current time of day; "tl" is seconds 
spent in execution; and "t2" is seconds spent in swapping. 
A command may be abandoned at any stage, including during 
the typing of the command line or during command output, by 
giving the "quit signal" peculiar to the console. 

Command Initiation 

At the time of the first clock trap following completion of 
a command line at a uer's console, that user is placed in 
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wa i t i ne-command status. He is then set at the 
scheduling queue which is chosen according 
assigning higher priority to shorter programs, 
user reaches the head of the h i ghest-pr i or i ty 
he will be placed into working status. 


end of a 
to a rule 
When this 
active queue. 


Program Termination 

A foreground program terminates its activity by one of two 
means. It can re-enter the supervisor in a way which 
eliminates the core image and places the user in a dea_d 
status; alternatively, by a different entry the program can 
be placed in a dormant status (or be manually placed there 
by the user giving a quit signal). The dormant status 
differs from the dead status in that a dormant user may 
still restart or examine his program. 

Input and Output Wait States 

User input-output to each typewriter is via the supervisor, 
and even though the supervisor has a few lines of buffer 
space available, it is possible for a program to become 
input-output limited. Consequently there is an i nput-wa i t 
status and an outout-wa i t status, into which the user 
program is automatically placed by the supervisor whenever 
input-output delays develop. When buffers become nearly 
empty on output or nearly full on input, the user program 
automatically returned to working status; 
computer time is avoided. 


thus waste 


i s 
of 


Schedu 1 i ng 

In order to optimize the response time to a user's command 
or program, the supervisor uses a multi-level scheduling 
algorithm. The basis of the algorithm is the assignment of 
each program as it enters working or waiting command status 
to an nth level priority queue. Programs are initially 
entered at a level which is a function of the program size 
(i.e., at present, programs of less than 4k words enter at 
level 2 and longer ones enter at level 3). There are 
currently 8 levels (0-7). The process starts with the 
supervisor operating the program which is first in the queue 
at the lowest occupied level, L. The program executes for a 
time limit = 2.P.L quanta; a quantum of time is one half 
second. If the program has not finished (left working 
status) by the end of the time limit, it is placed at the 
end of the next higher level queue. The program at the head 
of the lowest occupied level is then brought in. If a 
program P enters the system at a lower level than the 
program currently running, and if the current program PI has 
run at least as long as P is allotted, then PI will be 
returned to the head of its queue and P will be run. If a 
program changes its size, its new level is computed 
immediately. If the new level is different from the old, a 
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new maximum time is also computed and becomes effective 
ret roact ? ve 1 y . 

There are several different time limits whose current values 
may be of interest to the users. If a data phone is dialed 
into the computer and the user does not log in within 2 
minutes, there is an automatic hangup. If a program in 
working status waits one minute without being run, it is 
bumped to the next higher priority queue. If a user stays 
in any non-working status for one hour, he is automatically 
logged out. The clock burst which enables the supervisor to 
housekeep the console input and output and to change program 
status is currently set to 200 ms. The quantum of time used 
in the scheduling algorithm is one-half second. 

Memory Protection and Relocation 

To avoid fatal conflicts between the supervisor and multiple 
users, the CTSS IBM 7094 includes a special modification 
which behaves as follows: 

Core memory is divided into 256-word blocks. There are two 
7-bit protection registers which, when the computer is in 
its normal mode, can be set by program to any block numbers. 
Whenever a user program is run, the supervisor, as a final 
step just before transferring to the user program, switches 
the computer to a special mode such that if reference to any 
memory address outside the range of the protection register 
block numbers is attempted, the normal mode is restored and 
a trap occurs to the supervisor. 

There is also a 7-bit relocation register which modifies 
every memory reference, during execution, by addition of the 
relocation register block number. Thus programs which have 
been interrupted by the supervisor may be moved about in 
memory, if necessary, with only the proper readjustment of 
the relocation register required. 

Finally, if the user program, while in the special mode, 
should attempt to execute any instructions concerning 
input-output, changes in mode or core bank reference status, 
or resetting of the protection or relocation registers, the 
normal mode is restored and a trap occurs to the supervisor 
program in core bank A. Errors in this class are known 
generically as protection violations. 

User Communication with the Supervisor 


The supervisor performs a number of control functions which 
may be directly requested by the user. These include: all 
input and output (e.g., disk, drum, consoles, tapes); 
requests for information about or extension of the user 
program memory allocation; simulation of floating point 
trap; control of each user's status, interrupt level, and 
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i nput 
with. 


mode; and 
or control 


other functions which 
by, the supervisor. 


i nvol ve 


commun i ca t i on 


Since all protection violations cause a trap to the 
supervisor, users may conveniently communicate with the 
supervisor by means of such violations. Before rejecting a 
protection violation as a user error, the supervisor checks 
the possibility that it was caused by a user-program of the 
form 


TSX NAME1, 4 


NAME1 TIA =HNAME 

where NAME is the BCD name of a legitimate supervisor entry 
point. The details of each supervisor entry are described 
in section AG. The TIA instruction is described in IBM 
manual L22-6636; it may usefully (but inexactly) be read as 
Trap Into A core. 
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I Hent i f i cat i on 
Conventions of this manual 

This CTSS Programmer's Guide will be divided into 

in I function! 1 basis. The naming of the sections will be of 

the format MS.X.YY. 

M is the manual designation. Since the CTSS 
Programmer ' s Guide for the. IBM 7094 is the 
first manual in a series, its designation 
be "A". 

S is an alphabetic major section designation, 
e.g., this is section "B". 

y is the one or two digit subsection 
designation. This first publication will have 
subsections numbered from 1 to 13. Note that 
they will not be designated as 01 to 15. 

YY is the minor subsection designation. This is a 
two digit numeric designation ( 00, 01, u i . . . . ) 

The manual was prepared by. the CTSS f ,, co ™=" dS of TY ^ T n ^e 
RUNOFF where each section is. a separate the f ;ie 

MSXYY (MEMO). Note the deletion of periods within 

name . 

» ay j;r“thr p ^j«t c,, si*“r"ssi:t:;.r„ y 

thereof from me < j user's convenience copies 

documentation rooms. Or, at the user s , 

may be RUNOFF on the user’s 1050 Selectric console. 


The 


table of contents will be maintained in two forms. 


1 ) 


TABLE (MEMO) which may be RUNOFF, to produce 
the current table of contents in the form 
distributed with the manual U.e., 
sectional or functional order). The first 1 ' ne 
of TABLE will be dated to indicate the date of 

the latest change to the manual. Any , re Y'^'°^ 
of the manual will be. noted by date beside the 

section which was mo d i f I s d • 

2) DATTOC (MEMO) which may be RUNOFF to produce a 
table of contents in reverse chronoogi 
order of section modification. This will sho 
rapidly the latest changes to the manual by 
section and date. 

Within the text of the manual, areas of 
modifications will be noted by an asterisk n 
the right hand margin. This will be done only 
on one level of revision, that is, the flags 
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of any earlier revision 
the later modifications 


will be removed before 
are made. 


Because the manual will be done as much as possible with the 
current limited character set and as little hand work as 
possible by the typist, the following conventions will be 
used . 

1) The symbols designating "less than", "greater 
than", "less than or equal to", and "greater 
than or equal to", will be replaced by the MAD 
conventions of .L., .G., .LE., and .GE. 

2) Octal notation is expressed as the octal 
number enclosed in parentheses, followed by an 
8, e.g. (7777)8. 

3) Exponentiation is expressed in the MAD 
notation of .P. (e.g., 2. P.9). 

4) Optional arguments in calling sequences to 
subroutines will be enclosed within minus 
signs (e.g., -P2E BUFF-). This applies also to 
arguments to commands (e.g., -NAME2-). 

5) Indication for a literal within a subroutine 
calling sequence will be typed in lower case 
and be enclosed within single quotation marks 
(e.g. ' j ' ) . This means that the actual value 
should be used, rather than the location of 
the value. 

6) Some command arguments must be literal values 

and these will be shown as uppercase 
characters enclosed in single quotation marks 
(e.g., 'REV'). This means that no 

substitution is possible, but the actual 
characters shown must be used. 
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I den t i f i cat i on 

Glossary and Conventions 

Documentation Conventions 

Within calling sequences/ arguments written in upper case 
denote the location of a variable. Arguments in lower case 
denote the value itself. If literals are used, they are 
noted as such by the conventions of the language or as lower 
case letters enclosed in single quotation marks. Minus signs 
around an argument mean that argument is optional. 

There are three possible kinds of calling sequences for 
subroutines. The statement "as supervisor entry:" means that 
the user must supply the TIA as noted beside the TSX. The 
statement "as supervisor or library entry:" means that the 
user may supply the TIA as noted, or he may use the external 
library name noted in the TSX in which case the library will 
supply the TIA. The statement "as library subroutine:" means 
that the subroutine is an external library routine. A MAD or 
Fortran calling sequence will usually be given but the 
routine may also be called by the equivalent FAP calling 
sequence . 

Glossary 

* in front of an entry in the table of contents, 
indicates the new I/O system. An * in the 
right-hand margin, indicates a modification to 
the w ri te-up. 


% 


AC 36-bit signed accumulator. 

b denotes a required blank in a character 
string. 

C.R. carriage return. 

Console In general, the word console means a 
typewriter console (e.g., 1050, teletype) 

rather than a special display console (e.g., 
ESL scope). 

Current File Directory is the file directory to which 
the user is currently switched. It is usually 
the user's file directory but may be switched 
to a common file directory by COMF I L or to 
another user's file directory by ATTACH. 


External Routines are subprograms (with entry points) 
which are called by other subprograms. The 
library entries and library subroutines are 
external routines. The FAP calling sequences 
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give the entry point name. The FAP convention 
for calling external routines is: 1) EXTERN 
pseudo-op specification, or 2) preceding the 
name by $, or 3) CALL pseudo-op. All the FAP 
calling sequences in this documentation assume 
EXTERN specification so that the CALL and $ 
are not shown. 

Fence is a magic number used to designate the end of 
a vari able- length string of parameters. The 
fence referred to in this documentation is a 
word of all octal sevens. 

FILNAM is used in calling sequences to indicate the 
initial location of 2 BCD words containing the 
name of a disk file (right justified and 
blank padded). In Fortran programs, FILNAM may 
be set by the subroutine SETNAM or it may be 
the file name in H specification form. In MAD 
programs FILNAM may be set in a Vector Values 
s tatement . 

FMT or FORMAT is used in calling sequences to 
indicate the beginning location of a format or 
a location containing a pointer to the 
beginning of the format, if SETFMT is used. 

Library Entry - The majority of the required TIA's for the 
supervisor entries have been placed in the 
library as library entries. 

Line-Marked Files are files composed of variable length 
records. Each logical record is preceded by a 
word containing binary ones in bit positions 
0-17 and the number of words to follow in bits 
18-35. 

Line-Numbered Files are files composed of 14 word logical 
records. Characters 73-80 are a sequence field 
(the leftmost 3-6 may be alphabetic and the 
rightmost 2-5 must be numeric). 

LIST is used in calling sequences to provide a list 
of parameters to the subroutine being called. 
It usually specifies parameters for input or 
output. A list may consist of a combination of 
single variables, dimensioned or subscripted 
variables, or block notation as described in 
the MAD manuals. In Fortran, the implied DO 
may be used only in I/O statements, not in 
calls to subroutines. 

In MAD, a LIST might be: A, B ( 1 ) . . . B ( 10 ) , 
C(N)...C(1), G(J). The notation D(N)...N, 




CTSS PROGRAMMER'S GUIDE 


Section AB.2 


PAGE 3 


E(l). ..10, is also available in MAD but 
r currently is acceptable only to the new I/O 

system routines. 

Any FAP subprograms written after March 1 may 
be coded to accept this new format, but their 
write-ups should say so specifically. 

In FAP, a PEE prefix maybe used with the 
location of a single variable. 


The FAP equivalent of the above MAD LIST is: 
TXH A 

TIX B-l, , B-10 
TIX C- ' n ' , , C-l 
TXH G-'j' 

TIX D-'n',,N 

TIX E-1,,L(10) i.e., location of a 10 


Memory bound or allotment is the number of core 
registers available to the program, counting 
register 0. Therefore, the first unavailable 
register is equal to the memory allotment, 
except in the special case of (77777)8 when 
the entire 32,768 words of memory are meant. 

MODE With the previous file system, files could be 
one of four modes: 


j 


L • 


0. 

TEMPORARY 

- words are 

deleted 

as 

they 


are be i ng 

read or skipped over 

• 


1. 

PERMANENT 

can be 

read 

or altered 


indefinitely. 





2. 

READ-ONLY 

(class 1 ) - 

can 

be 

read 

but 


not altered until the 

mode 

i s 

changed . 

3. 

READ-ONLY 

(class 2 ) - 

can 

be 

read 

but 


not altered except by 

a 

control 

card 


submi tted 

to the d i spatche r 

• 




With the current file system there are eight 
modes and the mode of a single file can be any 
combination of the eight. 


000. 

PERMANENT 

001. 

TEMPORARY 

002. 

SECONDARY 

004. 

READ-ONLY 

010. 

WRI TE-ONLY 

020 . 

PRIVATE 

040 . 

LINKABLE 

100. 

PROTECTED 
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NAME1 NAME 2 are used in calling sequences to 
indicate the actual name of a disk file. 
NAME2 is the secondary (class) name. The 
actual names are right adjusted, blank 
padded, BCD words. 

String Files - files having no logical record 
breaks. Processed as strings of words by 
externally specified word counts. 

Supervisor Entry - supervisor routines which reside in 
A core can be entered only by a special 
calling sequence convention. 

TSX ROUT I N, 4 
ARGS 


ROUTIN TIA =HR0UT I N 

If the name of the routine contains fewer than 
six characters, the BCD word referred to in 
the TIA must be left adjusted and blank 
padded. The TIA's for many of the entries have 
been placed in the library as library entries 
in order to save the user the inconvenience of 
supplying the TIA, and to allow for tracing 
supervisor entries if the standard debugging 
aids are used. 
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I dentifi cation 
System documentation 
Purpose 

In order that the users may study the system and offer 
additions/ modifications/ or improvements/ the listings, 
source decks, and table of contents of the system must be 
available. There are two different user requirements which 
dictate two different kinds of documentation: 1) for the 
user who wants a complete listing of everything or at least 
a large volume of what is in the system, 2) for the user who 
wishes to study or modify a relatively small section. To 
satisfy the first user, there are document tapes. To satisfy 
the second there are source language files available on-line 
which may be assembled and listed by the user at his 
conso 1 e. 

User Procedure 

All source files will be CRUNCHed without sequence numbers 
and placed in CUMFIL 1 of M1416. The system module BS3 
files will also be in CUMFIL 1. The library BSS and command 
TSSDC. files will be in CUMFIL 2 of M1416, which is 
accessible to the user as COMFIL S. The listings and source 
files of modules, commands, and library routines will be 
maintained on document tapes which will be updated at least 
once a month. Between updating times, the listings of all 
modified files will be kept in CUMFIL 3 of M1416. Following 
the document tape update runs, these BCD listing files will 
be deleted from CUMFIL 3. All of these files will be 
LINKABLE, READ-ONLY, AUTHOR protected files. 

When a user modifies any component, the unmodified version 
(source and BSS) should be kept in his own file directory 
for a few days just as insurance since only the current 
version is maintained in the common files. All 
modifications should be documented to the extent of adding 
remarks to the front of the source file giving date, author, 
and purpose of modification. 


PUBLIC COMMANDS: 

When a new command is created, the SAVED file should be 
named ' COMAND TSSDC.'. The (MOVIE TABLE) file which is 
created by the loader should be named COMAND MOVIE) of 
permanent mode. The movie table will provide a table 
of contents and storage map of the command saved file. 
All of the source files used to create the BSS files 
which were loaded (except the library) should be 
CRUNCHed without sequence numbers and ARCHIVed into a 
file COMAND CRUNCH. All of the BCD listing files which 
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should have been created during the translation process 
should be ARCHIVed into a file COMAND BCD. The author 
may then submit a write-up to the manual editor and ask 
that the command be placed in the system as a public 
command. The responsible system programmer will then 
copy the above mentioned files into the common files 
and place the command in the system. If any of the 
required files is missing, the author will be notified 
and the command will not be entered in the system. 


AUTHOR MAINTAINED COMmANuB: 

The author may submit a write-up to the manual editor 
and ask that the command be placed in the system as a 
semi -public command. The documentation files are not 
required but it is strongly recommended that they be 
supplied as a courtesy. The documentation files may be 
author protected by the author rather than the system 
programmer so that the author may perform maintenance 
directly. The document files may either be copied into 
common files or linked to in the author's file 
directory from the common files Cto be decided by the 
system programmer as a function of size and track 
quotas). The manual write-up will direct all criticism 
to the author and the users are protected only by the 
integrity of the author. Users' remarks may be placed 
in the author's MAIL BOX and any documentation may be 
placed in the editor's MAIL BuX. 

LIBRARY: 

Any user may modify or submit a new library routine, 
but the mechanics of updating the library may be 
performed by only one or two people. Ghort library 
routines will be grouped into families in order to 
optimize track usage. A table of contents listing 
family names with the components' file names and entry 
points will be maintained in COmF I L 1 of M1416 as LIB 
INFO which may be PRINTFed. Each family will have a 
CRUNCned ARCHIVed source file in COMF I L 1 called FAMILY 
CRUNCH. Any single large routines will have a CRUNCHed 
source file called RuUTIN CRUNCH, The BBS files will 
be CUi'iBINed into the library file TGLIBn BSG. The 
listings will be maintained on document tapes and 
recently modified listings will be available in COMF 1 L 
3. A user who wishes to modify a library routine must 
supply all of these requested files to the system 
programmer who is responsible for the library. 

Additional information about the library routines, 
(entry points, transfer vector, length and use of 
common storage) is printed by the command PRBGS TGLIBn. 
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1) To retrieve a large volume of data, such as source 
decks or listings, requests may be submitted to 
the dispatcher for off-line processing of the 
document tapes. 

2) To obtain source files or listings of one or a few 
of the commands ? system modules, or the library, a 
user may LINK to the necessary files and: 

'PRINTF LIB INFO' If the required 

routine is a library 
routine and the 

f ami 1 y name i s 

unknown. 

'ARCH IV X' FAMILY 'CRUNCH' FILE If there is an 

ARCH IV file called 
FAMILY containing the 
required FILE. This 
extracts and creates 
FILE CRUNCH. 

'CRUNCH UN' FILE KIND 'NUMBER' will uncrunch and 

create FILE KIND with 
1 i ne numbers . 

'PRINTF' FILE KIND Will print the 

source file and 
thereby disclose what 
K I ND shou Id be, if 
unknown. 

The source file FILE KIND may now be modified and 
translated with listing, if desired. 

If a command is being inspected, the ARCH IV command may 
be used to print the table of contents of the COMAND 
CRUNCH file. 


Mai ntenance Proc edu re 

The few people who take the responsibility of actually 
updating the system must follow a set procedure. The 
following is a sketch of what these people must do. Either 
obtain from the modifying-user or do the work necessary to 
have a CRUNCHed (without sequence numbers) source file(s). 
For commands and library families, ARCHIV these crunched 
files and place them in COMF I L 1. Place the COMAND TS3DC. 
files in COMF I L 2. UPDBSS the library BBS files into TSLIBn 
BSS in COMF I L 2. Place the BCD listing files in COMF l L 3. 
Place the system module BSD files in COMF I L 1. One thing 
the responsible system programmer must do all the work for 
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is maintaining the document tapes. The way to do this is to 
maintain three separate files of the format of OUTPUT 
RQUEST/ i.e./ one for commands/ one for modules and one for 
library. Each time a routine is changed/ place a PUNCH 
entry in the appropriate request file. At the end of each 
month/ uncrunch the necessary files as specified in the 
request files. Then run three separate and special request 
dump runs which will create input tapes which may be used by 
FMS FAP UPDATE in conjunction with the current source 
document tapes in order to produce new document source and 
listing tapes. Delete the n-2 document tapes and the 
listings from CUMF I L 3. 
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Identification 
Equipment Configuration 

The primary terminals of CTSS are, at present, modified 
Model 35 Teletypes and IBM 1050 Selectric teletypewriters 
(adaptations of the "golfball" office typewriter). These 
are located mostly, but not exclusively, within the M.l.T. 
campus. Each of these terminals can dial, through the 
M.l.T. private branch exchange PBX, either the IBM 7094 
installation of Project MAC or the similar installation at 
the M.l.T. Computation Center. The supervisory programs of 
the two computer installations may, independently, accept or 
reject a call, depending on the identity of the caller. 
Access to the MAC System can also be gained from any station 
of the Telex or TWX 1 telegraph networks. Some tests and 
demonstrations have been conducted from European locations, 
and experiments are in progress in collaboration with a 
number of universities to provide further experience with 
long-distance operation of the system. 

Although Teletypes and other typewr i ter- 1 i ke terminals are 
adequate for many purposes, some applications demand a much 
more flexible form of graphical communication. The MAC 
System includes for this purpose the initial model of a 
multiple-display system developed by the M.l.T. Electronic 
Systems Laboratory for research in computer-aided design. 
The system includes two oscilloscope displays with character 
and line generators and light pens, as well as some 
special-purpose digital equipment that performs the 
light-pen tracking, and simplifies the task of the computer 
in maintaining the display, and in performing common 
operations such as translating and rotating the display. The 
two oscilloscopes can be operated independently of each 
other; communication with the computer can be achieved by 
means of the light pen, and also through a variety of other 
devices such as knobs, push buttons, toggle switches, and a 
t>pewriter. The meaning of a signal from one of these input 
devices is entirely under program control. The whole display 
system communicates with the IBM 7094 of the MAC 
installation through the direct-data channel, and the 
display data are stored in the central memory of the 7094. 
Because of cable length requirements, the display must be 
located in a room adjacent to the computer installation. 
Remote operation would require the addition of a memory and 
some processing capacity for local maintenance of the 
di splay. 

A separate, very flexible display terminal is provided by a 
DEC PDP-6 computer which can communicate from a remote 
location with the MAC computer installation through a 
1200-b i t-per-second telephone connection. 

All of these terminals can operate simultaneously with the 
MAC computer installation by time sharing its central 
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processor. In order to insure prompt response, the number of 
terminals active at a given time is limited by the 
supervisor program to 30. This number has already grown to 
30 from 10, and is expected to grow further in the next few 
months. However, maximization of this number is not a 
primary objective at this time. 

The IBM 7094 central processor has been modified to operate 
with two 32,768-word banks of core memory and to provide 
facilities for memory protection and relocation. These 
features, together with an interrupt clock and a special 
operating mode (in which input-output operations and certain 
other instructions result in traps), were necessary to 
assure successful operation of independent programs 
coexisting in core memory. One of the memory banks is 
available to the users' programs; the other is reserved for 
the t ime-shari ng system supervisory program. The second bank 
was added to avoid imposing severe memory restrictions on 
users because of the large supervisor program and to permit 
use of existing utility programs (compi lers, etc. ), many of 
which require all or most of a memory bank. 

The central processor is equipped with six data channels, 
two of which are used as interfaces to conventional 
peripheral equipment such as magnetic tapes, printers, card 
readers, and card punches. A thi rd data channel provides 
direct-data connection to terminals that require high-rate 
transfer of data, such as the special display system. 

The fourth data channel provides communication with a disk 
(IBM 1302) and a low speed drum (IBM 7320). The theoretical 
storage capacity of the disk is 38 million computer words 
and the capacity of the drum is 186,400 words. The time 
required to transfer 32K words in or out of core is 
approximately one second for both the disk and the drum. 

The fifth data channel provides communication with two high 
speed drums (IBM 7320A). The capacity of a 7320A is the same 
as that of the 7320 but the transmission time for 32K words 
is one-quarter second. 

The transmission control unit (IBM-7750) consists of a 
stored-program computer which serves as an interface between 
the sixth data channel and up to 112 communication terminals 
capable of telegraph-rate operation (up to 200 bits per 
second). An appropriate number of these terminals are 
connected by trunk lines to the M.l.T. private branch 
exchange and to the TWX' and TELEX networks. Higher rate 
terminals can be readily substituted for groups of these 
low-rate terminals; for instance, on the present MAC System, 
three 1200-b i t-per-second terminals are installed, one of 
which provides the communication channel to the PDP-6 
computer. All of these terminals are compatible with Bell 
System data sets. Part of the core memory of the 
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( transmission control unit is used as output buffer, because 

% « the supervisor program and its necessary buffer space have 

( grown in size to the point of occupying all of the A bank of 

* core memory. The design intent was and still is to provide 

sufficient input-output buffer space in the main memory to 
r : eliminate unnecessary core-to-core transfers; the present 

. mode of operation is a makeshift made necessary by equipment 

f 1 i mi tat i ons . 
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identification 

Clocks 


Purpose 

The CTSS IBM 7094 has an interval timer clock, available as 
well as Chrono log clock. The interval timer clock is 
completely under control of the supervisor; its action is as 
follows: location 5/ memory A, is incremented in the units 
position every 1/60 sec; whenever it overflows, an interrupt 
occurs which, if the clock is enabled, causes a trap to 
location 7 and the instruction location counter to be stored 
in location 6. The interval timer clock is more completely 
described in IBM Manual L22-6554. 


The supervisor uses this clock both for interrupting 
programs and for time accounting. Base-time and 
day-of-the-month information are obtained from the Chronolog 
clock which is attached as a pseudo tape unit. The 
supervisor can also simulate the interrupt clock behavior 
for each user. By supervisor calls, the user can program 
for nested interrupts and computation time readings. 


% 
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Id-anti f. i cat i o n 

Console character sets 
Purpose 

For routine computer work, especially older applications/ 
the normal 7094 BCD character set is sufficient for console 
messages. This set consists of 47 characters and blank/ 
augmented by a few console control functions, namely: 
carriage return, tabulation, back space, color shift, erase 
character, and kill message. This normal BCD set is 
contained in a 6-bit code and when the character mode switch 
of a console is set to "normal", the console will transmit 
and receive in the normal BCD mode. Consoles, however, may 
be switched to a "full" or 12-bit mode. The normal BCD 
character set has been extended to a 12— b i t character set by 
allowing the normal six to be preceded by either a zero or a 
one. The modes of the consoles are set by supervisor calls 
and the computer words being transmitted are either treated 
as six 6-bit characters per word or three 12-bit characters 
per word. 

Co d e tables 

The following tables present the character sets for 
different consoles. The 6-bit character set is listed under 
case-0. The 12 bit character set is listed under case-1. 
The case-1 characters which are listed in parentheses are 
ignored in 6-bit mode. Other case-1 characters (not in 
parentheses) are received in 6-bit mode as the corresponding 
case-0 character. The abbreviations used have the following 
mean i ngs : 


ig - ignored 
WRU - who are you 
P-off - Printing off 
P-on - Printing on 
erase - erase previous character 
kill - kill or delete previous message 
VT - vertical tab 
CR - Carriage return 
FF - form feed 
tab - horizontal tabulation 
hang up - data phone disconnect 
sngl spac - single space 
dbl spac - double space 
K.L. - Keyboard lock 
K.U. - Keyboard unlock 


An octal 57 is guaranteed to be a null character on output 
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INPUT/OUTPUT CODE TABLE 
FOR 1050 SELECTRIC CONSOLE 


Case 
£ 1 

00 o (°) 

01 1 ( + ) 

02 2 U) 

03 3 ig 

04 4 (#) 

05 5 ($) 

06 6 (0^ 

07 7 (line feed ) 

10 8 (sngl spac) 

11 9 (dbl spac) 

12 ig ig 

13 = ig 

14 ' ( l ) 

13 ig ig 

10 i g ( hang up) 

17 ig (P-Off) 

20 + & 

21 A a 

22 B b 

23 C c 

24 D d 


nmr r ^ UP 5 ‘ S sing,e Push of "Reset line' 
UUIT is double push of "Reset line" 


-Case 


Case 


£ 

25 E 

1 

e 

£ 

52 ig 

1 

ig 

26 F 

f 

53 $ 

i g 

27 G 

g 

54 * 

( prc 

30 H 

h 

55 CR 

i g 

31 1 

i 

56 'kill' 

? 

32 ig 

b 1 ack 

57 'quit' 

i g 

33 . 

red 

00 blank 

i g 

34 ) 

i g 

61 / 

i g 

35 : 

back sp. 

62 S 

s 

36 ig 

i g 

63 T 

t 

37 'erase' 

II 

64 U 

u 

40 - 

(_) 

65 V 

V 

41 J 

j 

66 W 

w 

42 K 

k 

67 X 

X 

43 L 

1 

70 Y 

y 

44 M 

m 

71 Z 

z 

45 N 

n 

72 tab 

i g 

46 0 

o 

73 , 

/ 

47 P 

P 

74 ( 

‘ g 

50 Q 

d 

75 i g 

(P-On 

51 R 

r 

76 i g 

i g 


77 ig 


i g 
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INPUT/OUTPUT CODE TABLE 




FOR 

THE 

MODEL 35 

TELETYPE 





Case 


Case 



Pass 



H 

1 


u 

1 


4 

1 

00 

0 

i g 

25 

E 

E 

52 

FF 

• g 

01 

1 

i g 

26 

F 

F 

53 

$ 

(1) 

02 

2 

(bell) 

27 

G 

G 

54 

* 

ig 

03 

3 

i g 

30 

H 

H 

55 

CR 

i g 

04 

4 

(=) 

31 

1 

1 

56 

'kill' 


05 

5 

(v) 

32 

i g 

i g 

57 

'qui t' 

i g 

06 

6 

(A) 

33 

• 

• g 

60 

b 1 ank 

i g 

07 

7 

(<) 

34 

) 

] 

61 

/ 

(K.L.) 

10 

8 

(>) 

35 

• 

• 

i g 

62 

S 

S 

11 

9 

(~) 

36 

i g 

i g 

63 

T 

T 

12 

i g 

i g 

37 

' erase ' 

ii 

64 

U 

U 

13 

= 

(«-) 

40 

- 

(_) 

65 

V 

V 

14 

i 

(1) 

41 

J 

J 

66 

w 

w 

15 

i g 

(WRU) 

42 

K 

K 

67 

X 

X 

16 

i g 

(hang up) 

43 

L 

L 

70 

Y 

Y 

17 

• g 

(P-Off) 

44 

M 

M 

71 

Z 

z 

20 

+ 

i g 

45 

N 

N 

72 

tab 

(VT) 

21 

A 

A 

46 

0 

0 

73 

/ 

/ 

22 

B 

B 

47 

P 

P 

74 

( 

[ 

23 

C 

C 

50 

Q 

Q 

75 

i g 

(P-On) 

24 

D 

D 

51 

R 

R 

76 

i g 

(K.U. ) 







77 

i g 

(Alt Mode) 


Interrupt is single push of "BREAK" 
QUIT is double push of "BREAK" 
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INPUT/OUTPUT CODE TABLE 
FOR THE TWX CONSOLE 



SL 

1 

SL 

00 

0 

i g 

25 E 

01 

1 

i g 

26 F 

02 

2 

(bell) 

27 G 

03 

3 

i g 

30 H 

04 

4 

(#) 

31 1 

05 

5 

( V 

32 ig 

06 

6 

(U) 

33 . 

07 

7 

(<) 

34 ) 

10 

8 

(>) 

35 : 

11 

9 

i g 

36 i g 

12 

i g 

i g 

37 'erase 

13 

= 

(-) 

40 - 

14 

i 

(1) 

41 J 

15 

i g 

(WRU) 

42 K 

16 

i g 

(hang up) 

43 L 

17 

i g 

(P-Off) 

44 M 

20 

+ 

& 

4 5 N 

21 

A 

A 

46 O 

22 

B 

B 

47 P 

23 

C 

C 

50 Q 

24 

D 

D 

51 R 


1 

Case 

SL 

1 

E 

52 FF 

> g 

F 

53 $ 

(t) 

G 

54 * 

i g 

H 

55 CR 

> g 

1 

56 'kill' 

? 

i g 

57 'quit' 

i g 

• g 

60 blank 

i g 

] 

61 / 

i g 

i g 

62 S 

S 

i g 

63 T 

T 

ti 

64 U 

U 

« g 

65 V 

V 

J 

66 W 

w 

K 

67 X 

X 

L 

70 Y 

Y 

M 

71 Z 

z 

N 

72 tab 

(VT) 

O 

73 , 

/ 

P 

74 ( 

[ 

0. 

75 ig 

(P-On) 

R 

76 i g 

i g 


77 ig 

(alt mode) 



CTSS PROGRAMMER'S GUIDE 


Section AC. 2. 01 


PAGE 5 


INPUT/OUTPUT CODE TABLE 
FOR THE TELEX CONSOLE 


Case 

H 1 


00 

0 

i g 

01 

1 

i g 

02 

2 

i g 

03 

3 

> g 

04 

4 

(#) 

05 

5 

i g 

06 

6 

i g 

07 

7 

i g 

10 

8 

i g 

11 

9 

i g 

12 

i g 

i g 

13 

i 

i g 

14 

■ 

i g 

15 

ig 

(WRU) 

16 

i g 

■ g 

17 

> g 

> g 

20 

& 

i g 

21 

A 

A 

22 

B 

B 

23 

C 

C 

24 

D 

D 


Case 

SL 1 


25 

E 

E 

26 

F 

F 

27 

G 

G 

30 

H 

H 

31 

1 

1 

32 

i g 

• g 

33 

• 

i g 

34 

) 

i g 

35 

bel 1 

• g 

36 

i g 

i g 

37 

1 erase ' 

ii 

40 

- 

• g 

41 

J 

J 

42 

K 

K 

43 

L 

L 

44 

M 

M 

45 

N 

N 

46 

O 

O 

47 

P 

P 

50 

U 

a 

51 

R 

R 


£ase 

SL 

52 ig 


53 

$ 

i g 

54 

* 

i g 

55 

CR 

i g 

56 

'kill' 

? 

57 

'quit' 

i g 

60 

b 1 ank 

i g 

61 

i g 

i g 

62 

S 

S 

63 

T 

T 

64 

U 

U 

65 

V 

V 

66 

w 

w 

67 

X 

X 

70 

Y 

Y 

71 

z 

z 


72 ; ig 

73 , ; 

74 ( ig 

75 ig ig 

76 i g i g 

77 ig ig 


H w> 
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I denti f i cation 

Special console characters 

Purpose 

When working at the console/ there are several significant 
signals or characters which the user finds necessary. The 
"break character" is necessary to signal the end of a line 
so that the supervisor knows that it is time to analyze the 
line to determine whether or not action is required. The 
"interrupt signal" is useful for the user to signal his 
program that the pre-planned branching within the program 
should now be followed. This might be analogous to sense 
switch interruption during batch processing. The "QUIT 
signal" is used to stop the current program by placing it in 
dormant and return the user to the command level. The "erase 
character" is interpreted before the line is processed by 
the supervisor and it causes the immediately preceding 
character to be erased by moving the character pointer or 
counter back one. The "erase or kill line" is also 
interpreted before the line is processed by the supervisor 
and it causes the deletion of the current line. 

Break Character 

The break character is a carriage return. Whenever a user 
types into his console/ regardless of whether his program is 
running or not/ the input character is received by the 
supervisor within 200 ms. The input character is added to 
the user's input message and if it is not a break character/ 
no further action is taken. If the character is a break 
character/ the message is called complete and one of several 
actions results. 

If the user was at the command level (i.e./ the user was in 
the dead or dormant status)/ he is placed in a waiting 
command status. If the user's program was in an input-wait 
status, it is returned to the working status so that it may 
resume by reading the input message. If the user's program 
was already in the working status, the message is merely 
considered early and is left in the buffer for subsequent 
reading by his program. (If early messages continue to 
arrive and the input buffer area becomes nearly filled, a 
message is typed out to the user requesting that he stop 
typing until his previous input is read.) 


Quit and Interrupt Signals 

When a program is first initiated or placed in working 
status it is said to be at interrupt level 0. This applies 
to both commands and user programs. The program continues 
execution until it terminates by entering dead or dormant 
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status or until the user transmits the QUIT signal which 
places the program in dormant status immediately and returns 
to level 0. This manual QUIT signal allows the user to 
change his mind/ correct mistakes/ etc. 

In addition to the basic level 0/ the user may extend the 
number of interrupt levels, thus allowing externally 
controlled branching to subsystems. This is accomplished by 
the program's issuing calls to the supervisor, which on each 
entry drops the level by one (to a maximum of 3) and 
specifies a return entry. Whenever a console interrupt 
signal is received by the supervisor, the level is raised by 
one and control is returned (by means of a push down list) 
to the entry previously assigned. 

The interrupt signal is sent from a 1050 selectric after a 

single push of the "RESET LINE" button. The QUIT signal is 

sent by a double push of the "RESET LINE" button. Qn the 

mdbcLh 5 telet yP e / the corresponding button is labeled 
BREAK • 


Erase and Ki ll Characters 

A console operating at command level is automatically set to 
the normal mode or 6-bit BCD code. (A program call to the 
supervisor is necessary in order to change to the 12-bit 
typing mode). While inputting in the normal mode, two 
special characters are recognized before the message is sent 
to the supervisor. The character " (quote) is interpreted 
as a single character eraser. This is accomplished by moving 
the character pointer back one space instead of forward 
within the current line or message. Therefore, n quotes will 
? ch^acters (not counting the quotes themselves as 
characters) back to, but not including, the previous 
carriage return orbreak character. The ? (question mark) is 
interpreted as a kill ordelete message signal. The entire 
message back to the previous break character is erased. 

Additionally, while in the 6-bit mode, the : (colon) is 

Th h r i[ eted H b - m ? St edlt pregrams as a one space backspace. 
This is used in formatted input which uses tabs, such as MAD 
input. For example, A tab : R puts the R in position 11 as 
required for remarks cards in MAD. 5 


CTSS PROGRAMMER'S GUIDE 


Section AC. 3 


PAGE 1 


I dent i f i cat ion 

Data phone extensions & console ID. 

Purpose 

The consoles may be connected with the MAC or CC machines by 
way of telephone lines through a special exchange or 
switchboard at M.l.T. Because of the difference in 
transmission rates/ certain lines must be used by 1050 
consoles and different lines must be used by teletypes. The 
exchange has the ability of searching several lines to find 
one which is not busy 7 and therefore certain numbers are 
specified as "hunt" numbers/ implying that a set of numbers 
will be searched as a result of dialing the "hunt" number. 

Consoles have specific/ but not unique/ identifications. 
These identifications are to be used in programming with the 
interconsole communication subroutines. The identification 
is a single BCD word/ consisting/ from left to right/ of a 
type code (1 for teletypes/ 2 for 1050's/ 3 for TELEX/ 4 for 
TWX')/ 2 to 4 BCD zeroes/ and 1 to 3 BCD characters of 
i dent i f i cat i on . 

Each dataphone used with an IBM 1050 console has a unique 
extension number which may be used for voice transmission 
between consoles rather than data transmission. 

Computer extension numbers: 


MAC computer: 
TELETYPES: 


HUNT 211: 211, 

212/ 213/ 

214/ 

215/ 

216/ 

217/ 

218 



HUNT 221: 221/ 

222/ 223/ 

224/ 

225/ 

226/ 

227/ 

228 



HUNT 231: 231/ 

232/ 233/ 

234/ 

235/ 

236/ 

237/ 

238 



1050: 









HUNT 311: 311/ 

312/ 313/ 

314/ 

315/ 

316/ 

317/ 

318/ 

319/ 

310 

HUNT 321: 321/ 

322/ 323/ 

324/ 

325/ 

326/ 

327/ 

328/ 

329/ 

320 

HUNT 331: 331/ 

332/ 333/ 

334 







Computation Center 

Computer : 








TELETYPES: 









HUNT 251: 251/ 

252/ 253/ 

254/ 

255/ 

256/ 

257/ 

258 



HUNT 261: 261/ 

262/ 263/ 

364/ 

265/ 

266/ 

267/ 

268 



1050: 









HUNT 361: 361/ 

362/ 363/ 

364/ 

365/ 

366/ 

367/ 

368/ 

369/ 

360 

HUNT 371: 371/ 

372/ 373/ 

374/ 

375/ 

376/ 

377/ 

378/ 

379/ 

370 

HUNT 381: 381/ 

382/ 383/ 

384/ 

385/ 

386/ 

387/ 

388 
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Locations and telephone extensions for teletypes: 


Loca t i ons 

Ext . 
No. 

1 . D. 

Code 

Mach i ne 
No. 

12 Oriole St., West Roxbury 

511 

1 

1 

26-157 

512 

2 

•2 

1-109,115 (jacked) 

513 

3 

3 

Harvard, 33 Oxford St., 

Cambr i dge 

514 

4 

4 

11 Holdenwood Rd., Concord 

515 

5 

5 

33-214 

516 

6 

6 

E19-319 

517 

7 

7 

26-157 

518 

8 

8 

52-454C, 560, 561, 562 
( j acked ) 

519 

9 

9 

26-265 

520 

10 

10 

Brown U, Comp Lab., 

180 George St. 

Prov i dence, R. 1 . 

521 

11 

11 

26-150 

522 

12 

12 

54-616 

523 

13 

13 

Boston U, Rm 5 700 

Commonwea 1 th 

524 

14 

14 

26-157 

525 

15 

15 

26-157 

526 

16 

16 

Lincoln Lab, B-232, A-166 
( j acked ) 

417 

17 

17 

Lincoln Lab, B-276, A-166 
( j acked ) 

418 

18 

18 

3-482 

419 

19 

19 

1-171 

420 

20 

20 

52-076A 

421 

21 

21 
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20D-102 

20B-120 

26-352 

14S-316 

32-108A 

T. S. 823 

111 Ivy St w Brookl ine 
T. S. 831 

295 Harvard St./ Apt 811/ 
Cambr i dge 

T. S. 809 

T. S. Conference Room/ 

8th floor 

T. S. 901 

96 Montvale Rd./ Newton 
Center 

T. S. 526 

14N-210 

58 Edgemoor Rd./ Belmont 
1-171 

33 Dawes Rd t/ Lexington 
T. S. 908 

35 Alcott St./ Acton 
T. S. 908 
3-463 
T. S. 920 

474 Putnam Ave, Apt 1, 
Cambr I dge 


422 

423 

424 

425 

426 

427 

428 

429 

430 

431 

432 

433 

434 

435 

436 

437 

438 

439 

440 

405 

406 

407 

408 

409 

410 


22 

23 

24 

25 
26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 


22 

23 

24 

25 
26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 
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2-366 


411 

47 

47 

1-155 (jacked) 

412 

48 

48 

4 Hilda Rd., Bedford 

413 

49 

49 

T. S. 920 


414 

50 

50 

T. S. 920 


415 

51 

51 

T. S. 920 


416 

52 

52 

T. S. 920 

( 33KSR ) 

510 

53 

53 

T. S. 920 

( 33KSR) 

540 

54 

54 

T. S. 931 

( 35ASR ) 

532 

55 

55 

6-320 


527 

140 

140 

Tufts, Comp Center, Medford 

528 

141 

141 

N51-310D 


529 

142 

142 

W91-223 


530 

143 

143 

26-145 


531 

144 

144 

54-1425 


469 

145 

145 

20A-121 


470 

146 

146 

24-019 


471 

147 

147 

16-011 


472 

148 

148 

26-263 


473 

149 

149 

26-261 


474 

150 

150 

26-259 


475 

151 

151 

16-157 


476 

152 

152 

26-157 


477 

153 

153 

26-157 


478 

154 

154 
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Locations and telephone extensions for 1050's: 


1-171 

541 

U 

63 

26-142 

542 

C 

60 

26-142 

543 

G 

61 

26-139 

544 

J 

62 

3-269 

545 

1 

64 

24-421 

546 

2 

65 

E19-325 (with attachments) 

547 

H 

66 

T. S. 404 (with attachments) 

548 

1 

67 

20D-004 

554 

P 

68 

26-153 

555 

3 

69 

52-582 

556 

4 

70 

26-265 

557 

5 

71 

26-265 

558 

6 

72 

26-265 

559 

7 

73 

26-265 

549 

8 

74 

61 Shattuck Rd., Watertown 

550 

9 

75 

1-150 

551 

V 

76 

26-144 

552 

C 

77 

26-169 

553 

1 

78 

T. S. 513, 512 (jacked) 

560 

• 

79 

T. S. 511, 513 (jacked) 

561 

• 

80 

T. S. 510 

562 

• 

81 

T. S. 509 

563 

• 

82 

T. S. 508 

564 

• 

83 

T. S. 507 

565 

• 

84 
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T. S. 506 

566 

• 

85 


T. S. 505 

567 

• 

86 

$ 

26-265 

568 

T 

87 


1-171 

441 

U 

100 


Lot 6, Deacon Haynes Rd., 
Concord 

442 

W 

101 


T. S. 803 

443 

A 

102 


T. S. 814 

444 

B 

103 


T. S. 806 

445 

D 

104 


T. S. 801, 836, 838 
( j acked ) 

446 

E 

105 


T. S. 920 (with 
a t tachments ) 

447 

F 

106 


T. S. 920 (with 
attachments ) 

448 

F 

107 


T. S. 926 

449 

K 

108 


T. S. 825 

450 

L 

109 


3-482 

451 

M 

110 


T. S. 801 (jacked) 

452 

N 

111 


24-522 

453 

0 

112 


14S-316 

454 

Q 

113 


4-107 

455 

R 

114 


T. S. 503 

456 

+ 

115 


T. S. 503 

457 

+ 

116 


T. S. 503 

458 

+ 

117 


T. S. 503 

459 

+ 

118 


T. S. 503 

460 

+ 

119 


24-109 

461 

$ 

120 


T. S. 822 

462 

S 

121 

ft 
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Lot 4, Deacon Haynes Rd . , 
Concord 

463 

/ 

122 

20B-226 

464 

/ 

123 

32-1 08A 

465 

0 

124 

Murray Hill, New Jersey 

466 

/ 

125 

T. S. 920 

467 

/ 

126 

T. S. 920 

468 

/ 

127 


Note: . (period) , (comma) 


) 
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I dent I f i ca t i on 
Historic file system 
Purpose 

The IBM 1301 disk served as the bulk storage for the time 
sharing system so that users files, system files and 
sub-system files could be quickly and randomly dumped and 
read. It was extremely important to have a flexible but 
efficient and usable central module which would handle all 
the disk input and output for all users. The following 
ideas were incorporated in the disk control subroutine which 
was used for about a year and a half. In April of 1965, the 
old disk control subroutine was replaced by a new module 
which incorporated many improvements, but also allowed for 
much upward compatibility for the old system. The old 
system will, therefore, be described here because of all the 
routines and write-ups which are still using the 
compatibility features. 

Cons ? derat ? ons 

The following considerations went into the make-up of the 
file system and they might help in the understanding of the 
system. 

1. The user should be able to write and maintain 
permanent programs and data files on the disk. 

2. System and subsystem programs should be 

permanently recorded on the disk. 

3. The user should have only symbolic reference to 

his files. 

4. The user should be able to read and write many 

files simultaneously. 

5. The user should not be able to reference any files 
not authorized to him. 

6. The user should be able to initiate files in 

different modes such as temporary, permanent, or 
read-on 1 y . 

7. In order to utilize the maximum storage capacity 
of the disk file the format of a single record per 
track should be used. 


Protect i on 

During time-sharing, all systems and users make use of the 
single standard input/output package. If a system does not 
use the standard routines, it can be run by itself with the 
disk inoperative or if it needs the disk, the contents of 
the disk can be dumped and later reloaded when time-sharing 
is restarted. During t i me-sha r i ng, the standard package 
makes use of input/output trapping and memory protection to 
insure protection of user's programs and files. The user 
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has access only to files which are authorized to him. 

A further protection against loss of files is the 
operational procedure of dumping the contents of the disk 
files periodically onto tape. These dump tapes can be used 
by a retrieval program to reload the disk completely or 
selectively. These history tapes are kept on file by 
operations according to a schedule which is approximately: 
daily tapes for a week, weekly tapes for 4 months and yearly 
tapes forever. In case of a major unrecoverable catastrophe 
the entire system may be backed-up 24 hours by reloading the 
most recent dump tape. The user may recover any of his 
individual files from any of the tapes which contain them. 

File S t ructure 


cdcn .o cooifincu one or more tracks to serve as a 
directory of all his private files currently stored on the 
disk. A user does not have access to any other user's file 
directory. A group of users who may be working on the same 
problem may be assigned an extra set of file directories 
(called common files) to which all the users of the srouo 
have access. s ' uup 


The old system had two severe limitations: first onlv 
user could be working in a file directory at any one 
and second, that a reference to a single file could 

3 ^ lngle f ,[ 1e d ' r ectory. These limitations 
that in order to share routines or data, users had to 
ti es into and out of common files, so that there 
multiple copies of the same file. Furthermore, whenever one 
user was using a common file, no one else had access to it 

These limitations have been much alleviated with the new 
system. " ew 


one 
t i me, 
exist 
meant 
copy 
were 


to the 
usage 
tracks 
of a 


The file directories contain the two BCD word names, the 

T. Zr° f , tra S kS “ sed ' the starting trac( < address pointer, 
last_u ? ed / and the mode of each file. A master 
tie directory is maintained which contains a pointer 
lie directory of each user in the system. A track 
table is also maintained which tells the system which 
are already used and which are free. All the tracks 
single file arechained together by virtue of the first word 
of each track either pointing to the next track in this file 
or to the last word of this track if there are no more 
tracks. Wheneve r . poss i b 1 e, the tracks for one file are 
assigned consecutively, in order to reduce the time lost in 
seeking. When the disk is reloaded from the dump tapes, the 
housekeeping is done to provide consecutive tracks for 
files which might previously have been scattered 
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Usage 

All files are referred to by a two word BCD name and no 
absolute track locations are known or needed. All calling 
sequences to the disk routines provide the facility of 
allowing the user to specify his own error procedure or 
accept the standard system error procedure. All of the 
calls and error procedures are described in section AG of 
this manual. Almost all of these calls will have 
write-around. routines for the new I/O system so that they 
will behave in much the same way as they did before April 
1965. Note that in the table of contents of this manual, 
the sections which refer to the new I/O system are preceded 
by an *. 
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I dent i f i cation 

The new file structure and Input/Output system 
Purpose 

The new file system was implemented/ 1) in order to continue 
the basic philosophy of the previous file system and remove 
many of the weaknesses which had become evident in its years 
of exercise and 2) to provide and exercise a prototype of 
the file system which is proposed for the next time sharing 
sys tem. 

Some improvements to be found in the new system will be 
mentioned here, and it is assumed that the reader is 
familiar with the previous file system discussed in section 
AD.l. The I/O system will operate all available channels in 
parallel, simultaneously for one or many users. This is a 
necessary requirement for a mu 1 1 i -programmed supervisory 
system. The I/O system can accomodate any configuration of 
I/O channels and/or devices and thereby provide a standard 
interface to all users. The protection feature, of having 
files dumped onto tapes which can be saved for retrieval, 
will be accomplished by a daemon which is in constant 
operation during time sharing. In this way the amount of 
information which is dumped and the amount of time lost due 
to back-up will be greatly reduced. The I/O system can now 
deal with entries in file directories which are pointers to 
entries in other file directories rather than to the files 
themselves. This means that a user may permit other users 
to use any of his files without actually copying the desired 
files into other directories. Thus, many users may be 
referencing files within the same directory, simultaneously. 
Indeed, many users may be reading the same file. The lock 
does exist that no one may reference a file which another 
user is altering. A further improvement is an increase in 
the number of modes which files may have. Additional 
entries have been added to the I/O system to allow the 
administrators to update the master file directory during 
time sharing operation so that new users can be placed in 
the system more quickly. The I/O system is modular for all 
machine dependent sections, by replacement of certain 
modules, different strategies for particular I/O devices, or 
I/O devices themselves, may be changed without affecting the 
overall I/O structure. 

Structure of the I/O System 

The I/O system presents a standa rd machine independent 
interface to all users. All calls to the I/O system are 
directed to the basic control module of the system called 
the File Coordinator. The File Coordinator then requests 
service from the Buffer Control Module, which in turn may 
request service from a particular strategy Modules. A 
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Strategy Module is concerned only with a certain class of 
information storage. The Strategy Module may in turn 
request service from an I/O Adapter. The I/O Adapter is a 
module which processes input and output requests for 
specific I/O devices. All calls to the I/O system 
requesting input or output must follow this path of control, 
the File Coordinator- the Buffer Control Module- the 
Strategy Module- the I/O Adapter. 

The File Coordinator: 

The File Coordinator provides the interface between the file 
system and the user. It interprets the calling sequences, 
performs validity checking of the calls, and calls the 
appropriate module. 

The Buffer Control Module: 

The Buffer Control Module is called by the File Coordinator. 
Its functions are to maintain the user's active file status 
table parameters, to convert the user's calling sequences to 
appropriate I/O commands for the stategy modules, and to 
move the data words between the buffers and the user's data 
storage area. The Buffer Control Module in turn calls the 
appropriate Strategy Module when I/O is needed. 

The Strategy Modules: 

Each Strategy Module is responsible for a particular storage 
device. This module determines the strategy to be used in 
dealing with this storage device and its associated I/O 
Adapter. In addition, the Strategy Module is responsible 
for keeping track of the number of available units of 
secondary storage for the device to which it is assigned. 
Requests are made to the Strategy Modules only through the 
Buffer Control Module. 

The I/O Adapters: 

The I/O Adapter is responsible for the operation of the 
hardware interface to a particular device or devices. The 
I/O adapter accepts requests for service from the Strategy 
Modules only. These requests are stacked in queues to be 
executed whenever the associated channel becomes free. The 
I/O adapters are responsible for processing all traps 
associated with the devices to which they are assigned. The 
I/O adapters interrupt the appropriate Strategy Modules upon 
completion of previous requests. 

Operation of the Buffer Control Module 

The buffer control module ( BCM ) is called by the file 
coordinator and its function is two fold: 1) maintain the 
users active file status table parameters of file length. 
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reading and writing status and pointers, buffer status and 
pending I/O, and 2) convert the user's calling sequence into 
appropriate calls to the I/O adapter for physical records 
and move data between the buffers and the user's data area 
on a word basis. 

Whenever possible, data is moved directly from the I/O 
device into the user's data area without going through a 
buffer. In the general case, however, a buffer must be 
supplied for intermediate storage for those parts of the 
data which do not comprise a complete physical record on the 
I/O device. Some users may wish to devise more 
sophisticated I/O control when the system efficiency is 
considered unsatisfactory, so the following conditions are 
noted where files may be dealt with without providing a 
buffer. For example, a multiple buffers system may be built 
in the user's program without extra buffering by the system. 

Reading without a buffer: 

If blocks of integral number of physical records are read or 
if reading goes through the end of file, no buffer will be 
used even if one is assigned. 

If no buffer is assigned and partial records are called for, 
the physical record will be read for each call in order to 
extract the logical or partial record from the physical. 

Writing without a buffer: 

A complete new file of any length can be written by a single 
call without a buffer being assigned. 

An existing file may be written into without a buffer only 
from the beginning of a physical record through the end of 
a physical record or through the end of a file. 

Appending to a file or writing partial records requires a 
buffer . 

Truncation without a buffer: 

Truncation without a buffer can only be accomplished if the 
truncation word is beyond the end of file or in front of the 
first word (file made empty). 

The BCM selects an appropriate strategy depending on whether 
a buffer has been assigned or not and returns an error if a 
buffer is mandatory where none was assigned. A user may 
switch a file from "no-buffer" mode to "buffer" mode or 
vice-versa by calls to BUFFER. 



f 
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File Notation and Structure 

The smallest piece of information which can be manipulated 
by the I/O system is an element. A file is an ordered 

sequence of elements. The file is the largest amount of 
information which can be manipulated by the I/O system. 

Every file will have a unique name which is used to identify 
that file to the user. An element in a file is referenced 
by specifying the file name and the linear index. For 

example/ the element "i" in file "a" is referred to as a(i). 
Files may be created/ modified or destroyed by a user only 
through the use of the I/O system. 

A file appears to the user to be a block of contiguous 

storage which may be referenced through normal sequential 

addressing conventions. However/ the physical structure of 
the file is independent of the logical structure which the 
user experiences. The user may refer to a file only through 
the symbolic file name and should have no notion of where or 
how the file is stored. The number of elements which make 
up a file is arbitrary/ and in fact a file may exist with no 
e 1 ements. 

There are four basic operations for manipulating elements 
within files. These are, opening, closing, reading and 
writing. To initiate a read and/or write operation, the 
file must first be opened for reading and/or writing, by the 
user. To terminate the reading and/or writing of a file, 
the file must be closed. 

Modes : 

A characteristic of every file is its mode. The mode of a 
file is specified by a 7-bit mask at the time it is created. 
(The mode may be changed later if desired.) Each bit in the 
mask indicates a different property of the file, and any 
combination of properties may be specified. The properties 
and the (octal) mask bit positions are shown below. 

000. PERMANENT- If all bits in the mode mask are zero, 
the file can be read or written, and will be stored 
i ndef ini te 1 y . 

001. TEMPORARY- Such a file will automatically be 
deleted the first time it is read. The deletion 
will not take place until the file is closed after 
read i ng . 

002. SECONDARY- This property defines files which may 
be deleted by storage collection mechanisms in 
preference to other files. 
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004. READ-ONLY- The file can only be read. An attempt 

to write into a file of this property will cause an 
error condi ti on. 

010. WRITE-ONLY- The file can only be appended to. An 
attempt to read from a file with this property will 
cause an error condition. 

020. PRIVATE- The file can only be referenced by. the 
AUTHOR i.e. the user who created or last modified 
this file. 

040. LINKABLE- The file may be referenced, by other 
users/ through the use of the "LINK" facility. 

100. PROTECTED- The mode of the file may only be changed 
by the AUTHOR of the file. Any attempt by another 
user to change the mode of this file will result in 
an error condition. 

File D i rector i es : 

The File Coordinator may service requests .from a fixed 
number of active users. Requests from a specific user are 
in the form a(i), to reference the element "i" in the user s 
file " a ”. The File Coordinator however, manipulates 
information by use of an implicit address of . the f°[ m 
cCbCaCi))). This address references the element i m the 
file "a", which is specified by the file "b", which in turn 
is specified by the file "c". The file "c" in this case is 
a specific Master File Directory and the file b is a 
specific User File Directory. The user will specify c and 
"b" with one call to the I/O system. Each successive call 
for a ( i ) will then be interpreted by the I/O system as 
c( b( a( i ) ) ) , until another call is given specifing a new c 
and "b" file pair. By treating the user file directories 
and the master file directories as normal information files, 
multiple usage of single files can be accomplished in a 
general manner. 

The formats of the Master File Directory and the User File 
Directories is shown on the next page. The groups of words 
1-7 actually begin in the fourth word of the file and^ are 
repeated in the groups of seven for each entry in the file. 

The dates are of the format: bits S,l-8 contain the 
-400 modulo 500, bits 9-12 contain the month, bits 13-17 
contain the day, and bits 18-35 contain the number of 
seconds elapsed since midnight. 

The AUTHOR is the programmer number of the user who created 
or last modified the file. The Fisa 3-bit integer which 
specifies on which secondary storage device the file 
resides. If F is 0, the entry refers to a linked file. F 
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is used by the Buffer Control Module to determine which 

strategy module should be called. 

RCOUNT specifies the number of elements contained in a 
Physical record of the file. NOREC specifies the number of 
physical records contained in the file. LCOUNT specifies 
the number of elements contained in the last physical record 
of the file. The highest element address in a file may be 
defined as (NORECS-1) * RCOUNT + LCOUNT. The 3-bit integer 
P i s no rma 1 1 y one . 

I LOCK is used to allow multiple users to access the same 
file simultaneously. If a file is in read status, I LOCK 
contains a count of the number of users currently reading 
from that file. If a request is made to modify a file, the 
high order bit of I LOCK is set to 1. When the number of 

users reading, from the file drops to zero, any user who 

wishes to modify that file will be allowed to proceed. 

During the time that I LOCK indicates that a modification to 

a file is on request or in progress, no new users will be 

allowed to reference that file. 

If user "A" wishes to reference a file contained in some 
other user s file directory (user "B"), he can accomplish 
this by means of a "LINKED" file. A LINKED file is defined 
in a user s file directory as a file with a device 

specification of zero (F=0). When user "A" references a 

file which is linked to user "B", the MODE of the 

corresponding file directory entry for user "B" must include 
the LINKABLE property. 

If a file in a user's file directory is a LINKED file (F=0), 
RCOUNT, NORECS and I LOCK are ignored. The problem and the 

programmer number of the user to which the link is made are 

in words 3 and 4. The name of the file being linked to is 
in words 6 and 7. A file may be linked in this manner 
through the file directories of several users. The last 
entry must be a normal file directory entry which defines 
the file in a normal manner. Once this linking operation is 
completed, the file will be treated as a normal file. This 

operation will be repeated every time a user attempts to 

open a L I NKED file. 

The user may refer to his file directory as a file of the 
name "U.F.D. (FILE)" which is defined in his file directory 
as a normal file in READ-ONLY mode. The Master File 
Directory is defined as a User File Directory by the name 
M.F.D. (FILE)" in the Master File Directory. This file is 
also referred to as "U.F.D. (FILE)" within the Master File 
Directory. To read the Ma ster File Directory, first, ATTACH 
($M.F.D.$,$(FILE)$). The I/O system will never allow the 
Master File Directory to deleted, regardless of which name 
is used to reference it. 
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MASTER FILE DIRECTORY, "M.F.D. (FILE)" 


WORD CONTENTS 

1. USER PROBLEM NUMBER (36 BITS) 

2. USER PROGRAMMER NUMBER (36 BITS) 

3. DATE AND TIME LAST MODIFIED (36 BITS) 

4. DATE LAST USED (18 BITS), AUTHOR (18 BITS) 

5. (8 BITS), (10 B I TS ) , F (3 BITS), RCOUNT (15 BITS) 

6. (3 BITS), NORECS (15 BITS), P (3 BITS), LCOUNT (15 BITS) 

7. The next "P" words contain specific information for a file 
of type "F". 


USER FILE DIRECTORY, "U.F.D. (FILE)" 


WORD CONTENTS 

1. FILE NAME, PART 1 (36 BITS) 

2. FILE NAME, PART 2 (36 B ITS) 

3. DATE AND TIME LAST MODIFIED (36 BITS) 

4. DATE LAST USED (18 BITS), AUTHOR (18 BITS) 

5. MODE (8 BITS), I LOCK (10 BITS), F (3 BITS), RCOUNT (15 BITS) 

6. (3 BITS), NORECS (15 BITS), P (3 BITS), LCOUNT (15 BITS) 

7. The next "P" words contain specific information for a file 
of type "F". 
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1301/1302 Disk and 7320 Drum Strategy 

The file directory entry for a 1301, 1302 or 7320 file 
contains pointers to the first and last tracks. For a file 
of this type, RCOUNT will be the number of data words in a 
single track. NORECS will be the total number of tracks in 
the file and LCOUNT will be the number of data words in the 
last track. 

Each track in a file of this type will contain chain address 
pointers to the following and preceding tracks. In addition 
each track will contain a label in the following form: 

I LCOUNT I TRAKNO I 
S 35 

TRAKNO is a track sequence number. LCOUNT will be non-zero 
only in the last track of a file and will contain the count 
of the number of data words in that track. This count must 
match the value of LCOUNT in the user file directory for 
that file. 

T&acks are assigned in a manner similar to that described in 
memo CC-196 (Disk Control Routine). All track usage tables 
will be files contained as entries in the Master File 
Directory. The file which defines the usage of disk tracks 
will be referred to as "DISCUT (FILE)". The track usage 
file for the 7320 drum will be referred to as "DRUMUT 
(FILE)". Whenever possible, successive tracks of a file 
will be assigned to separate channels. This procedure will 
allow all available disk/drum channels to operate on a file 
in parallel. 

1301/1302 Disk and 7320 Drum I/O Adapter 

The disk/drum Strategy Modules provide calls to the 
disk/drum I/O adapter specifying only logical track 
addresses. The I/O adapter Is responsible for determining 
the actual channels which must be used. The adapter places 
all requests into a request queue and returns. The trap 
processor for the disk/drum I/O adapter empties the request 
queue on completion of previous requests for that channel. 
If a request Is made requiring a channel not already in 
operation, a trap will be simulated for that channel. 

Tape Strategy Module 

Magnetic tapes will be treated as secondary storage in the 
same manner as disks or drums. Many files can be recorded 
on a single tape or set of tapes, and a single file may 
consist of more than one tape. The first physical record of 
a tape file will be a BCD header label of five words. The 
first two words of the header record are the original file 
name, the next two words contain the date and time when the 
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file was initiated, and the fifth word will be the tape 
sequence number. The first tape of a file will always have 
the sequence number "1". All subsequent records on the tape 
will be in blocked binary format. 

In a file directory entry for a tape file, RCOUNT will be 
432 and P will be one. The seventh word of the file 
directory entry will contain an internal tape address known 
to the I/O and supervisory systems only. Other information 
in the file directory entry has the same meaning as 
described in the disk and drum Strategy Modules. 

Each data record will contain 432 information words and in 
addition will contain a control word in the following form. 

PZE RECNO, , LCOUNT 

RECNO will be the record sequence number. LCOUNT will be 
non-zero only in the last record of a file and will be the 
count of the number of words in that record. This word 
count must match the value of LCOUNT in the file directory 
ent ry for that file. 

If a file consists of more than one physical tape, the 
physical tapes will be terminated by an end of file followed 
by a control record, written in BCD. This record will 
contain information, such as the next tape sequence number 
to be used. 

The I/O adapter for the tape Strategy Module will operate on 
request queues in the same manner as the disk and drum I/O 
adapters . 
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Usage 

Note three things in particular about this I/O system. 
First, it is basically not a buffered system so that upon 
return from RDFILE or WRFILE it is safe to assume that the 
I/O has not actually been done yet. Before the specified 
data area may be referenced/ a call to FCHECK and a 
"finished" return must be made. In other words, before a 
satisfactory delay has been made by FCHECK, the input data 
is not really there or the output data has not yet been 
transmitted so the user may not rewrite the data area. The 
second thing of note is that if an error return is 
specified, some errors are detected immediately and some are 
not detected until the next I/O call. Each RDFILE or WRFILE 
serves as an FCHECK on the preceding RDFILE or WRFILE on the 
same file. The third thing to note is that all of the I/O 
is considered to be by relative locations so that all files 
can be considered to be similar to addressable storage. 

Calling Conventions: 

Following is a list of calls to the new file system. The 
detailed write-ups of these calls can be found in section AG 
and in the table of contents their sections will be preceded 
by an *. Their calling sequences are given in MAD notation 
and the MAD compiler has been modified slightly to accept an 
integer or an integer-variable specifying the number of 
words in block notation rather than the last address of a 
block. The new file system is consistent in expecting the 
number of words rather than the last address in block 

notation. All arrays are stored forward so that the 

beginning address must be the lowest core location of the 
array. Also, all file names are specified by the locations 

of both BCD names rather than the location of the first name 

as F I LNAM is used in the old file system. The file names 
are right adjusted and blank padded. For example: 

MAD: FSTATE. ($ NAME 1$ , $ N AME 2 $ ,A ( 8 ) . . . 8 ) 

FAP : TSX FSTATE, 4 

TXH =H NAME1 

TXH =H NAME 2 

TIX A, ,EIGHT or TXH A, ,8 


• 

EIGHT PZE 8 
A BSS 8 

In all of the calls, if an argument is not pertinent, a -0 
may be specified. All calls will accept two more arguments 
than shown. The first is the location of users' error 
return and the second, if supplied, specifies the location 
into which the error code will be stored. 
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Some of the arguments and information items are 
forms which might be noted here. 


of special 


DEVICE = 


File status = 


1 . 

i s 

low speed 

drum 

2. 

i s 

disk 


3. 

i s 

tape 


1 . 

i s 

i nact i ve 


2. 

i s 

open for 

read i ng 

3. 

i s 

open for 

writing 

4. 

i s 

open for 

read i ng 


SUMMARY 


Administrative and Privileged: 


PROBS , $ PROGS) 

PROBS / S PROGS) 

PROBS, $ PROGS) 

NAME1S , S NAME2S, $ PROBS, S PROGS) 

oriril _. w NAME1S, $ NAME2S,DAYTIM / DATELU / M0DE / DEVI CE) 

LINK.($NAMElS,$NAME2$,$PROBN$,$PROG$,-$NMIS-,-$NM2$-,-MODE-) 

ALLOT. (DEVI CE, -ALLOT-, -USED-) 


UPDMFD . ( S 
DELMFD . ( $ 
ATTACH . ( $ 
MOVFI L. ($ 
SFTFI L. (S 




Reading and Writing: 


OPEN . ( SSTATUSS, $ NAME1S,$ NAME 2 S , -MODE- , -DEV I CF- ) 
BUFFER. ($ NAMF1S , $ NAME2 $ , BUFF ( 43 2 ) . . . 43 2 ) 

RDF I LE . ( $ NAME1S , S NAMF 2$ , RFLLOC , A ( N ) . . . N, -EOF-, -EOFCT- 
WRF I LE . ( $ NAME1S, $ NAME 2 $ , RELLOC, A ( N) . . . N, -EOF-, -EOFCT- 
TRF I LE . ( $ NAME1S , $ NAME 2 $ , REL LOC ) 

FCHECK . ( $ NAME1S , $ NAME 2$ , F I N I SH ) 

CLOSE. ($ NAME1S , $ NAME2S) 


) 

) 


others : 

SETPRI . (PRIOR) 

RESETF . 

CHFILe!($ NAME1$,$ NAME2$,-NMODE-,-$NEWNMl$-,-$NEWNM2$-) 
DELF I L . ( S NAME1S , $ NAME2S ) 

FSTATE . ( $ NAME1 $ , $ NAME2S , A ( 8 ) . . . 8 ) 

UNLINK. ($ NAME1S , $ NAME2S ) 

STORGE. (DEVI CE, -ALLOT-, -USED-) 

MOUNT. (-CHAN-,UNIT,MESSAG(20) . . .20) 

UMOUNT. (UNITNO,MESSAG(20) . . .20) 

VERI FY.(UNITNO,LABEL(4) . . .4) 

LABEL. (UNITNO, LABFL(4) . . .4) 

TAPF I L . ( $ NAME1S , $ NAME 2$ , UN I TNO, FI LFNO ) 

IODIAG. (A(7). . .7) 

Tl LOCK. (RETRN) 

FERRTN. (RETRN) 
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I dent i f i ca t i on 
Library files 
Organ i za t i on 


Library files are created by COMBINing BSS files into files 
which may then be searched for missing routines by the 
relocating loaders. Any user may create his own library 
files and, by use of the special arguments, direct the 
loader to search his library files instead of (or in 
addition to) the CTSS system library files. Subsystems of 
CTSS (e.g., AED) may have their own libraries and their own 
loaders. However, the ones being discussed here are the 
CTSS system library and loaders. 

The system library is currently divided into files which 
reside in the system common file directory. TSLIB1 contains 
all of the standard routines described as library 
subroutines and library entries in this manual. The loader 
will normally search TSLIB1 for missing routines unless 
prohibited by special arguments. TSLIB2 contains the 
debugging subroutines and core-B transfer commands. The 
loader will search TSLIB2 automatically only when a core-B 
transfer command has been given. If the debugging routines 
are to be loaded with the program before execution the 
loader should be informed by (SYS) TSLIB2 or, for example, 
more completely by (NEED) F LEX PM (SYS) TSLIB2. A special 
library in the system file is KLULIB which contains 
subroutines for the "KLUDGE" (i.e., ESL scope console) and 
which may be searched if special arguments are given to the 
loader. The old library (prior to October 1964) still 
resides in the system file. It may be used with the (OLD) 
special argument to the loader. It is being neither 
maintained nor updated by the system maintenance staff. 

The library files may be improved by any user by following 
the maintenance procedure described in section AB.3. The 
library is maintained by the programming staff at the 
Computation Center. 















- 

- 
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I dent i f i cat i on 
COMMON Files 
Purpose 

Within the former file system, a single file could be 
referenced from only one file directory and only one user 
could be attached to a file directory. In practice/ a group 
of users could be working on one problem and, therefore/ 

have need to access a common pool of programs and data. 

This conflict was partially resolved by implementing the 
concept of common files. A group of users working on the 
same problem was assigned a single problem number. Each 
problem number could then have associated with it as many as 
four common file directories. Any user could switch from 
his own file directory to one of the common file directories 
associated with his problem number. With appropriate calls 
to the supervisor a user could copy any of his files into 
the common files or copy files from any of the common files 
into his own directory. Some restrictions still existed, 
namely, only one user could operate in a common file 
directory at any one time; to avoid locking users out of a 

common file, files had to be copied and, therefore, many 

copies of the same file existed; and common files were 
associated with a problem number and therefore communication 
between problem numbers was impossible. 

System Files 

The four common files associated with the system 
programmers' problem number took on the special function of 
servicing all users, regardless of problem number. Their 
common file 4 became known as the public file and any user 
could put files there and copy files from there. In order 
to housekeep the public files, the disk editor, which was 
run at least once a day, deleted all files in the public 
file which were in temporary or permanent mode. Only a 
system programmer could change a file in public to R1 or R2 
mode. A further restriction has been placed on the public 
file, namely, only programs which are adequately documented 
may remain in public. The documentation is available from 
the consultants. The system programmers' common file 2 
became known as common file S and any user could copy files 
from there. Common file S contained the binary files of all 
the commands and the BSS files of the libraries. The system 
programmers' common file 1 contains the source and binary 
files of the supervisor and common file 3 contains listing 
files of the supervisor. 

Changes to Common Files 

With the advent of the new I/O system and the ability of 
many users simultaneously to access the same file, the need 
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for the public file has diminished. Any file may be 
declared linkable by any or all users and, therefore, only 
one copy of it needs exist. 

The public file under the new I/O system is a file directory 
of track quota 0 and is merely a directory of links to files 
in other directories. Files which are needed by commands 
will exist in the system file (common file S) and linking 
pointers to_them will exist in the public file directory. 
If a user wishes to place a file in the public file, after 
proper documentation is available, a link pointer to the 
file may be placed in the public file directory by a system 
programmer. The actual file may remain in the user's file 
directory or a decision may be made to place the file in the 
system file. 

The concept and implementation of common files will continue 
for compatibility purposes but they are no longer needed. 
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I dent i f i cat i on 
Time-accounting files 


Purpose 

Tu p t ! mp-account i ng files contain crucial user information 
uch'rpassScHs^time allotment,. P-'ty «r°uP n ™ -s, 
etc These files are read and written by LOGIN and LOGUUi, 
and* they can be updated by a few privileged commands. 


Def i n i t i ons 


who is permitted to use the time sharing system 
a unique programmer number (4 numeric digits). 

• i 


Each person 

Depend i n^on" the ' number'of "j'o'bs he" u^der takes, he w! 1 1 also 

numeri^cha r °cters J^'^Groups^of - peop^e^workt ng^on 30 the same 
problem may be assigned the same problem number . Wl hen 

user logs in, he types his problem number and e. 

The combination of problem number and last six characters 
the last name is neither unique nor secret A s 1 ch te £ 
secret password, is therefore requested by LOGIN so that ^ 

CH - Ck b!na a t < ?on°Lrsts! CC ?he , uniq^ < ^combination defines a 

single user'and a single file directory, with Us a “°^at e d 

sj'ssss'r J&rsz “ tI sK.:K 
ss-sw-sr- SSui' 

!l^ nU :Mch 0f 8 wr%ccess° m to d 1hr e crputer (see Sect, on 
AH. 1.01) . One of these lines is assigned to a 


as soon 


i s 
has 
has 


exhausted, 
the power 
the effect 


as he logs in. When the number of lines 
new users may log in. The administrator 
give a user a line mu l t i pi i e.r which 

assigning more than one line to the user when he og in 
thereby reducing the number of users who may logged 

Each user is also assigned to a unit gro u£. Each unit gro p 
specifies which consoles the user may or may not use. 


no 
to 
of 
and 
i n. 


Desc r i Pt i on of files 


files: 


There are four time-accounting -ft 

PRTYGP, and GRPUNI with secondary name btuKti. 


UACCNT, USDTIM, 


UACCNT : 


The file UACCNT contains identifying 
user. LOGIN searches UACCNT for the user 
name, and password; this combination must 
the person can be logged in. 


information for each 
's problem number, 
be found before 
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This file consists of 14-word lines. These lines are 
f ree-f leld w? th blanks as the delimiter of the fields. 
However, the first character of each line has a particular 
meaning. If the first character is blank (b), the line is 
taken as a continuation. 

The first line in file UACCNT must be a problem number 
master line: 


* PROBNO DF1 CF1 TF1 DF2 CF2 TF2 
b DF3 CF3 TF3 DF4 CF4 TF4 

DFn drum quota for nth common file for this 
problem number. 

CFn nth common file quota on disk. 

TFn nth common file quota on tape. 

The first character of this line must be '*'. 

Following the problem number master line comes all the 
programmer information for the programmer numbers which 
belong to this problem number. The first character of a 
programmer information line must be something other than 
or blank. Programmer information must be in this order 
reading from 1 ef t-to-r i ght . 

NAME PASSWORD PROGNO RQDR RQDS RQTP 
b TA1 TA2 TA3 TA4 TA5 PRTY S LMULT 
b UNIT RESTRICTION 


RQDR 

RQDS 

RQTP 

TAn 

PRTY 

S 

LMULT 

UNIT 

RESTRICTION 


user's quota on drum, 
user's quota on disk, 
user's quota on tape, 
time alloted for nth shift, 
user's party group number. 

standby indicator, if non-zero user can be 
standby. 

user's line multiplier , 
user's unit group number. 

user's restriction code (privileged calls). 


The amount. of. information on each line is arbitrary, the 
on 1 y res t r i ct i on being that there can be no more than ten 
continuation cards. 


Following the user information lines is the next problem 
number. master line followed by the user information 
belonging to that problem number, etc. 
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USDTIM: 

The file USDTIM contains the following information for each 
user : 

TUn Time used for each shift. 

DATE1, TIME1 Date and time of last logout. 

DATE2, TIME2 Date and time from which used time has 
accumulated. 

TL Total time logged in since DATE2, TIME2. 

This file has a fixed format. There are two lines per user. 
Format of line 1 : 

Characters 1-6 7-12 13-18 

PROBNO PROGNO NAME 

Format of line 2 : 

Char. 1-6 7-12 13-18 19-24 25-30 31-36 37-42 43-48 49-54 55-70 
DATE1 TIME1 DATE2 TIME2 TUI TU2 TU3 TU4 TU5 TL 

LOGIN reads the USDTIM file each time someone logs in. If 
the user is not found in this file, LOGIN adds him. to the 
file with zero times used. LOGOUT updates the time used 
information and re-writes that portion of the file 
containing information on the user logging out. 


PRTYGP : 

The file PRTYGP contains the party group information and the 
maximum number of users. This file consists of 14-word 
1 i nes . 

The first line of the file contains only the maximum number 
of users. 

The rest of the lines contain pairs of numbers (XXX b YYY). 
The pairs of numbers must be separated from each other and 
other pairs by at least one blank (b). The number of pairs 
per line is arbitrary. 

XXX group number 

YYY number of 1 i nes for group number XXX 


LOGIN reads this file to determine whether a user will be 
logged in as primary or as standby. 


* GRPUNI: 

The file GRPUNI defines groups of consoles the user may or 
may not be allowed to use. Each unit group begins with a 
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line of 14 words, containing the unit group number and a 
number equal to 14 times the number of lines describing this 
group. Each following line contains a word indicating 
whether this list of consoles is allowable or not / followed 
by the list of console ID's. If the first word of the line 
is blank, or zero, the consoles on that line are available 
to the user. If the first word is anything else, the user 
is not allowed on the consoles whose ID's are in the line. 
If the unit group contains a list of available consoles, the 
user must be on one of them. If, however, the group 
contains only consoles on which he is not allowed, and he is 
not on any of them, the user is logged in. 

An example of the GRPUNI file: 

Characters 1-6 7-12 13-18 19-24 25-30 

15 28 

nnn ID1 ID2 

nnn I D3 I D4 

25 56 

ID5 I D 6 

ID7 

ID8 

ID9 

30 28 

I DIO I Dll 

nnn ID12 I D 1 3 

The dots indicate additional ID's, or blank fields, which 
are skipped. Each line is 14 words long. The first unit 
group, group number 15, has 28 words following the first 
line. Group 15 consists of consoles the user is not allowed 
to use, as indicated by the first word on each line being 
non-blank. Group 25 contains four lines of console ID's 
all of which are available to the user, as indicated by the 
first word on each line being blank. The user must be on 
one of these consoles. Group 30 contains both allowable and 
non-allowable consoles. Since this group contains a list of 
consoles the user is allowed on, he must be on one of them. 
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Bulk input and output 


Since the console is a relatively slow input/output device, 
it is necessary and desirable to have a means of entering 
programs and data into the disk files from card decks and 
conversely to be able to output disk files onto cards or the 
high speed printer. Files may be punched on cards in such a 
format that they may later be reentered into the system to 
exactly duplicate the original file. In this way, cards may 
serve as a permanent, inexpensive back-up. 


The disk editor program is run several times a. day by the 
operations staff. Request cards may be submitted to the 
dispatcher by the user or the RQUEST command may be used to 
create a line-numbered card image file called OUTPUT RQUEST. 
Each line within the OUTPUT RQUEST file is the equivalent of 
a control card and may, therefore, specify any of the 
following requests except INPUT. The format of each 1 i ne is 
the same as a control card except the PROB PROG must not be 
specified. See Method, below. 

The control cards for the disk editor are of the format: 

XX PROB PROG NAME1 NAME 2 OP ... NAMEln NAME 2 n 
The fields are separated by one or more blanks or a comma. 

PROB is the problem number. It must not be 

specified in an OUTPUT RQUEST file. 

PROG is the programmer number. It must not be 

specified in an OUTPUT RQUEST file. 

NAME1 NAME 2 is the file name. Most requests allow 
more than one file name per card with the 
restriction that the file name must be 

complete on one card, i.e., NAME2 may not be 
on a continuation card. 


XX=C Continuation card 

X X = I NPUT This card must precede a card deck to be input 
to the disk. The last card of the deck must 
have *E0F* beginning in column 8. Only one 

file name may appear on the control card and 
OP may specify the desired mode in octal for 
the file. If OP is not specified, a permanent 
file will be created, or if a file of the same 
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XX=PRI NT 

XX=DPUNCH 

XX=BPUNCH 

XX= 7PUNCH 

XX=DELETE 

XX=CARRY 


name already exists, the mode will be 
preserved. 

The BCD file NAME1 NAME2 is printed off-line. 
If the file is not line marked, a blank word 
is inserted at the beginning of the line to 
insure single spacing and the first 84 
characters of the record are printed. If the 
file is line-marked, the first character is 
the carriage control character and the rest of 
the line, up to 131 characters, is printed. 

The BCD file NAME1 NAME2 is punched off-line. 
If the file is line-marked, just the first 80 
characters per line of data will be punched. 

The binary card image file NAME1 NAME2 will be 
punched off-1 ine. The 7-9 punch and checksums 
should already be included in the card image 
file. 

The file NAME1 NAME2 (of any format) will be 
punched off-line in a special card format 
which may be reloaded by the disk editor to 
reproduce the file exactly. The file is not 
deleted from the user's directory. 

The file NAME 1 NAME 2 will be deleted from the 
current file directory. 

The file NAM El NAME2 will be carried to the 
other computer and will be loaded onto the 
disk during the next load or update. It will 
be loaded in permanent mode, with the same 
name ( NAM E 1 NAM E2), within the s ame 
problem-programmer file directory. If a 
different problem-programmer specification is 
desired for the receiving file directory, OP 
may be PR0B1 PR0G1, (i.e., the desired problem 
programmer numbers). If a different file name 
is desired, OP may be PR0B1 PR0G1 NAM1 NAM2, 
where PR0B1 PR0G1 must be the problem 
programmer numbers for the receiving file 
directory and NAM1 NAM2 is the name to be 
gi ven to the i nput file. 

The file NAME1 NAME2 on this machine is in no 
way changed. Any previous versions of the file 
on the receiving machine will be deleted 
regardless of mode, but the mode will be 
preserved by the new file. 
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XX=PRNDEL; DPUDEL; BPUDEL; 7PUDEL: 

The file(s) will be PRINTed, DPUNCHed, 
BPUNCHed, or 7PUNCHed and then the mode will 
be changed to temporary. The next time the 
file is read or the user logs out, the file 
will be deleted. This is safer than a process 
request followed by a DELETE request. In case 
of machine or tape failure during the 
processing of the request/ the operations 
staff will have the opportunity of restarting 
the disk editor. 

XX=CHF I LE Change the name and/or the mode. of. NAME1 
NAME2. Only one file may be specified in one 

request. OP is MODE NEW1 NEW2 . MODE is the 

octal value of the new mode or * if the mode 
is not to change. NEW1 NEW2. are the new 

names; either may be * i f it is not to be 

changed from the original. Both NEW1 NEW2 may 
be omitted if only the mode is to change. 

Method 

The disk editor is a background job which is run several 
times a day by the operations staff. The users file 

directories are searched for OUTPUT RQUEST files. When such 
a file is found/ the editor ATTACHes to the user s file 
directory and processes the requests found in OUTPUT RQUEST. 
Because the editor knows who the user is/ PROB PROG need not 
be specified in the OUTPUT RQUEST file. Due. to the file 
system locks/ the user will not be able to edit the OUTPUT 
RQUEST file while the disk editor is processing it. The 
OUTPUT RQUEST file will be changed to temporary mode by the 
disk editor after it is processed. After all OUTPUT RQUESTs 
have been processed/ the editor may read cards from the 
background input tape. As a result of the requests, the 
editor may create three output tapes which are then the 
responsibility of the operations staff, namely punch tape, 
print tape and carry tape. 
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Identification 

DAEMON - Disk Dump and Reload 
M. J . Bailey - x6 00 6 

Purpose 

For the purpose of user's file retrieval and catastrophe 
reloading of the disk, the contents of the disk must be 
written onto tape at some specified intervals. With the 
former file system, the entire content of the disk was 
written onto two sets of tapes at least once each day. 

With the new file system a new approach is being taken to 
the problem of back-up tapes. A program called the DAEMON 
runs as a console-less foreground user continuously, except 
when a complete reload is being performed. The operation of 
the DAEMON will be controlled by the operator from the 
console keys under the guidance of on-line printer messages. 
The DAEMON can perform three separate functions. It may be 
instructed to perform a complete dump, at which time the 
entire contents of the disk will be written onto tape. This 
will normally be done once a week. The complete dump tapes 
will be divided into two sections, one for the system files 
(SDT) and another for the users' files (UDT). The DAEMON 
will be instructed to do incremental dumping as its normal 
continuous operation. The incremental dumping will consist 
of writing onto tapes (NFT) only those files which were 
modified or created since the last incremental dump tape was 
closed. The files will normally be written onto tape only 
after a user logs out. The volume of output to the 
incremental dump tapes should be considerably less than that 
of the complete dump tape. The third function of the DAEMON 
is to reload the system. An independent program will be 
used to reload the system files (including the DAEMON 
program) from the SDT tapes. As soon as the system files 
are loaded, the DAEMON will be called to complete the 
reloading from the remaining user dump tape (UDT) and 
incremental dump tapes (NFT). This final reloading will 
also be performed during time-sharing. 

Retrieval of specific files can be requested by specifying 
the date of the last complete dump tape or specifying the 
date and time of the desired version from an incremental 
dump tape. Details of retrieval will be published at a 
later time. 
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DIAGRAM OF DISK FILE BACK-UP AND RETRIEVAL 
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I dent i f i cat ion 

Restrictions for Background Programs 

Purpose , . , 

Any programming system that is to be run as background in 
CTSS must observe certain conventions or restrictions. 
These conventions arise due to two main system requirements, 
that the background program be interruptible and that 
changes of state are a CTSS supervisor function illegal for 
the background to perform. The main area of a program 

affected is its input and output which must be timing 
i nsens i t i ve . 

Restrictions 

Change of state: , . , 

All changes of state are trapped by the protection mode 
hardware but certain ones are processed by the 
supervisor and allowed/ such as EFTM (enter 

floating-point mode). The following instructions are 
not allowed and/ if used/ will cause an on-line 
d i agnost i 

ECTM 
ESNT 
ESTM 
ETM 


I/O timing: 

Input and Output must be programmed so tnai it «=> ->ul 
timing dependent; thus the LCHX (load channel) 
instruction is prohibited. An RCHX (reset and oad 
channel) instruction/ if given, must immediately follow 
the select instruction. An exception is made for the 
on-line printer and punch where up to 3 SPR s, bRU s 
and/or NOP's can come between the Select and RCHX 
instructions. If an RCHX is given that does not comply 
v/ith these conventions, it will still be executed but 
its execution will turn on the I/O check light since it 
was not given "in time". 

I/O flag: 

All I/O commands (including TCH) must have a_"l" in bit 
20, tag of 1 to FAP, to indicate that the information 
is to be transferred to or from B core. A diagnostic 
will be given if this condition is not met. 

The FAP assembler accepts the pseduo-op, BCORE, which 
automatically includes this bit 20 in all I/O commands 
such as I OCD , I0RT, TCH, etc. And flags any illegal 
instructions used. 


c: 


LPI 

LRI 

SEA 

SEB 


TIB 


l _ _ i. L — . 4 - t 4- i r n A f 
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I/O units: 

Only the following l/o units are available for 
background systems: 

a. card reader, card punch, and printer 

b. tape units A1-A6, A10, B1-B6, BIO 

c. A7, the chronolog clock 

Referencing of other units will cause a dianostic. 
Program stop: 

Any planned system stop should be effected by an HTR 
instruction rather than an HPR. The instruction 
counter is set differently on the two instructions and 
due to this difference the HPR if interrupted does not 
cause a genuine program stop. Example: 

A HTR Instruction counter set to A; 

resumption after interrupt at A. 

B HPR Instruction counter set to B+l. 

resumption after interrupt at B+l. 

Any FAP program using the BCORE pseudo-op will 
automatically have all the HPR's flagged. 

Channel traps: 

Data channel traps on channels A and B operate normally 
except that when a trap occurs, control is transferred 


to location 

13 

o r 

15, 

wh i ch 

must contain an 

uncond i t i ona 1 

transfer . 

( 1 n 

no rma 1 

operating mode. 

when a trap occurs. 

the 

contents of 

13 or 15 are 

executed by 

i nstruct i ons . ) 

an 

XEC 

and 

need 

not be transfer 


Console keys: 

Operating procedures have been modified to limit 
operator intervention in such a way that no foreground 
user or the CTSS supervisor is affected. The address 
portion of the keys is used by the supervisor for this 
function and therefore cannot be used by a background 
system. The keys are used to simulate the following 
functions: 

a. depressing the "Load Cards" button, 

b. depressing the "Start" button, 

c. depressing the "Load Tape" button, 

d. initiating "a standard error" procedure. 

A "standard error" procedure is defined as: storing 

the instruction counter in a prearranged location and 
transferring control to another prearranged location 
(normally a transfer to a post-mortem routine or to the 
background system itself). The background system 
specifies these two locations to the CTSS supervisor by 
the following call: 
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TSX DEF ERR/ 4 

PZE ERRI LC// ERRTRA 

where DEFERR contains: TIA =HDEFERR. ERR I LC is the 
location where the instruction counter will be stored 
and ERRTRA is the location to which control will be 
tranfer red. 


Independent of operation: 

If the background system is to be designed to operate 
independently of the CTSS supervisor/ then the 
background system must be able to verify its mode of 
operation. A means of determining this so that a 
switch can be set is to execute the following 
i ns truct i ons : 


TSX TESTSS/4 


TESTSS TIA L 

L TRA 1/4 


(1/4) return if running 
i ndependentl y 
(2/4) return if running 
wi th CTSS 


If running with CTSS supervisor/ the TIA is interpreted 
as a regular supervisor call with a 2/4 return. If 
running independently/ the TIA L operates as if it were 
a TRA L; thus the 1/4 return. 

T i mers : 

The subroutines for determining the time operate 
properly whether the background system is running 
independently or not. The FMS subprogram GETTM can be 
used to read the date and time of day from the 
chronolog clock. The FMS subprogram TIMR can be used 
to determine elapsed time from the interval timer clock 
but when running with CTSS the operation of the 
interval timer clock is simulated and only incremented 
every 200 ms. (as opposed to every 1/60 th of a second 
when running independently). 
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I dent i f i cat i on 

General I/O without format specification 
RDF LXA/ RDFLXB, RDFLXC, WRFLX, WRFLXA 

Purpose 

To read from or print on the console without format editing. 
Usage 

As supervisor or library entries: 


TSX 

P2E 

RDF LXA/ 4 
LOC// 'n' 

opt i ona 1 ( T 1 A 

= HRDF LXA) 

TSX 

PcE 

WRFLXA/4 
LOC// 'n' 

opti onal ( T 1 A 

= HWRF LXA) 

TSX 

P2E 

WRFLX, 4 
LOC// 'n' 

opt i ona 1 ( T 1 A 

= HWRF LX ) 


RDFLXA reads a line from the console and moves n 
words into core beginning at location LOC. 
The AC will contain the value k, where the 
break character is the kth character (12-bit 
mode/ the break character is the k/2 

character). The word containing the break 
character and subsequent words are padded with 
blanks. If the break character is not 

received before the supervisor's input buffer 
is full, bit 21 of the AC will be l x 
indicating that another call to RDFLXA is 
required to continue reading the line. In 
this case, k will be a multiple of six. 

WRFLXA will print n words beginning at location 
LOC. It does not add a carriage return at the 
end of the line and does not delete trailing 
blanks. 

WRFLX will print through the last non-blank 
character within the n words beginning at 
location LOC. Trailing blanks will be deleted 
and a carriage return inserted after the last 
non-blank character. 

As library subroutines: 

RDF LX : 


TSX 
Pi E 


RDF LX, 4 
LOC// 'n 


I 


/ / 
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RDF LX will read a line from the console usin t 
RDFLXA. It will then strip the break 

character from the line, pad any remaining 
characters up to n words with blanks/ and move 
the n words into core beginning at location 
LOC. If n is less than the number of words 
read, the characters in excess will be lost 
( n . LE . 14 ) . 

RDF LXB / RDFLXC: 


MAD: 


FORTRAN: 

FAP: 


A= RDF LXB . ( LOC/ K ) 
A= RDFLXB (LOC/K) 
TSX RDF LXB/ 4 
P2E LOC 
P2E K 
ST0 A 


; A= RDFLXC. (LOC/K) 
; A= RDFLXC (LOC,K) 
or TSX RDFLXC/4 


LOC is the beginning location of an array into 
which information is to be stored. If called 
by MAD or FORTRAN/ information will be stored 
backwards from LOC. If called by FAP (i.e., 
PZE prefix)/ information will be stored 
forward from LOC. The array LOC must be at 
least (k+5)/6 words long. A line of more than 
14 words may be read with one call. 


K contains the value k which is the number of 
6-bit characters to be read. 

A will contain a right adjusted integer equal 
to the number of 6-bit characters actually 
read. 


RDFLXB using RDFLXA, moves k characters including 
the break character into LOC. Remaining 
characters up to k are blank padded. 

RDFLXC is the same as RDFLXB except that k and A 
do not include the break character. 
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Identification 

Set the console character mode switch. 

SETFUL/ SETBCD 

Purpose 

To set the console character mode switch. 

Usa ge 

As supervisor or library entry: 

TSX SETFUL/ 4 optional (TIA =HSETFUL) 

Sets the console character mode switch to 
"full" 12-bit mode. 

TSX SETBCD/ 4 optional (TIA =HSETBCD) 

Restores the console character mode switch to 
the "normal" 6-bit BCD mode. 

Upon return from either entry, the AC is zero 
if the previous setting was 6-bit mode, 
non-zero if the previous setting was 12-bit 
mode . 

Both library entries may be called by MAD or 
Fortran programs. 

Restrictions 

Any completed lines waiting in the input buffer are reset 
(lost) by either of these calls. 

Characters making up an incomplete line (that is, before the 
carriage return has been typed) are not reset by calls to 
SETBCD or SETFUL. 











































CTSS PROGRAMMER'S GUIDE 


Section AG. 1.03 


PAGE 1 



EXECUTE PRNTP . (MESS) 

VECTOR VALUES MESS = $ ho 1 1 e r i th str i ng$, 777777777777K 
FORTRAN: 

CALL PRNTP (nH hollerith string) 

PRNTP, the hollerith string up to the fence prints, 
on the user's console, 14 words per line. The 
string may be of any length. If the fence is 
(377777777777)8, there will be no carriage 
return at the end of the message. The fence 
which Fortran automatically supplies is 
(777777777777)8. 

PRNTPA, instead of PRNTP, inserts a carriage return 
every 14th word, with no carriage return at 
the end of the message. 

PRNTPC, instead of PRNTP, inserts no carriage returns 
at all. Users must supply what they wish in 
order to control the printing. 


t 

1 

1 

r 

l: I 
III 


II 

fi- 

ll' 


» 
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Identi f i cation 


Inter-user communication 
WRMESS, RDM ESS/ ALLOW/ FORBID 

Purj>a££ 

To provide the facility for users to communicate with each 
other directly, several routines have been added to the 
supervisor which allow the sending and receiving of messages 
by way of the console input buffers. Privacy screens have 
been provided which "allow" or "forbid" the sending of 
messages by specified users. 

Me th od 

1) Short messages may be sent to another user's 
console input buffer. 

2) Selectively/ short messages may be received 
in one's own console input buffer, from other 
users. 

3) The console input buffer may be read. 

Usage 

To send a message: 

As supervisor entry: 


PRGBN 


TSX 

WRMESS, 4 

CTI A 

=HWRMESS ) 

PZE 

=HPRUBN 



PZE 

=HPRUGN 



PZE 

LUC,, 'n' 



i s the 

problem number 

of the 

rece i ver 


character right adjusted with leading blank). 


PROGN is the programmer number of the receiver (4 
digits right adjusted/ leading blanks). 

LUC is the beginning location of the message to be 
sent ( forward) . 


n is the number of words in the message 
beginning at LUC. If n is larger than 12, a 
value of 12 will be used. 


Upon return, if the AC is non-zero, it contains an error 
code which indicates that the call was unsuccessful. The 
following error codes have been assigned. 


1 - The specified receiver is not a current user 

of CTSS. (i.e. logged in). 

2 - The receiver's input buffers are full. 
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3 - The receiver has not given permission for the 
sender to send messages to his input buffer. 

If the AC is zero, the first word of the receiver's input 
buffer will then contain an octal 77 in character 1, and the 
sender's problem number in characters 2-6. The second word 
will contain the sender's programmer number/ right adjusted 
and blank padded. The n words of the message will begin in 
the third word. If n is less than 12 the terminal words of 
the 14 word buffer will be blank padded. 

To read a message from the input buffer: 

As supervisor entry: 

TSX RDMESS/4 (TIA =HRDMESS ) 

PZE LOC/ / ' n ' 

ALPHA OPN EMPTY 

Normal return 


n words will be moved from the input buffer into 
locations beginning at LOC. 

If the user's input buffer is empty at the 
time of this call and ALPHA contains a zero y 
the user is placed in input wait status. I f , 
however/ ALPHA does not contain a zero, 
control returns to ALPHA. 

To be selective about who shall send messages to the user: 

As supervisor entry: 


TSX ALLOW/4 (TIA =HALL0W ) 

PZE =HPR0BN 

PZE =HPR0GN 


PROBN is the problem number and PROGN is the 
programmer number of the programmer who may 
use WRMESS to send messages to the user's 
console input buffer. Each call to ALLOW 
overrides all previous calls. 


If PROGN is zero, all programmers on problem 
number PROBN may send messages. 

If PROBN is zero, programmer PROGN may send 
messages, whatever his problem number. 

I f both PROBN and PROGN are zero, any 
programmer may send messages. 
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lock everyone out: 

As supervisor entry: 

TSX FORB I D 7 4 (TIA =HF0RB I D ) 

FORBID prevents any programs from sending lines 
the user's console input buffer. 


to 





] 
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Identi f i cation 
dlave remote consoles 

ATT CUN, RELEAi, oNUL I N, iNDLNA, KEDL I h, G LAVE, GETE, SET12 
Purpose 

To allow multiple remote consoles simultaneously to serve as 
l/U devices for a single program. 

Def i ni tions and Conventions 

The console at which a user logs in is his home conso 1 e . 
Uther consoles associated with a user have been attached by 
him, and they remain attached until he re 1 eases them. 

a console attached to one user may not simultaneously be 
attached to any other user. An attached console may not 
simultaneously be the home console of any user. 

An attached console which automatically transcribes into its 
output each character typed into the attacher's home console 
is an Jil slave . Similarly, an attached console which 
imitates the home console's output is an j,H) slave. An 
attached console whose typed input appears as input at the 
home console is known as an JJ_ s lave . 

As described in AC. 3, each console is permanently associated 
wi th a 0 -character conso 1 e i denti f i cation word . These 
console l.d.'s are central to the present facilities. 

Immediately after it has been dialed i n . a console is in an 
unat tachab 1 e state. 

a quit signal issued from an una t tachab 1 e console causes 
that console to become attachab 1 e . 

A quit signal issued from an attachab 1 e console causes that 
console to become una t tachab 1 e . 

A quit signal issued from an a t tached conso 1 e wh i ch i s not 
-3-Q J_L slave releases that console and leaves it 
MjattachahlP. 
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Usage 

To attach a console: 

As supervisor entry: 

TSX ATTCON, 4 (TIA =HATT CON ) 

PZE CONSOL 

CONSOL Is the location containing the 6 character 
console identification of the console to be 
attached . 

Upon return/ the AC will be zero if the designated 
console is '(HOME)', attachable/ or already 
attached to this user. The AC will be non-zero 
and no attachment made, if the designated 
console is attached to another, the home 
console of any user, or otherwise inaccessible. 


To release a console: 

As supervisor entry: 


TSX RE LEAS, 4 

PZE CONSOL 


(TIA =HRELEAS ) 


Upon return, the AC will be zero if the designated 
console was attached (and therefore is now 
released) or was '(HOME)'. In all other cases 
the AC will be non-zero and no action taken. 


To send a line: 

As supervisor entry: 


TSX SNDLIN/4 
PZE CONSOL 
PZE LOC, , ' n ' 
ALPHA OPN FULL 

normal return 


(TIA =HSND L I N or =HSND LNA ) 


The line to be sent to the designated console's output 
buffer is n words long and begins at location 
LOC. 

SNDLIN eliminates trailing blanks and adds the carriage 
return at the end of the line. 


SNDLNA does not eliminate blanks and does not add the 
carriage return before sending the line. 

CONSOL If CONSOL is '(HOME)', the line is sent to the 
user's home console output buffer. If the 
designated console is not attached to the user, 
return is to the normal return with the AC 
non-zero. 
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ALPHA If the output buffers at the designated console 
are full and ALPHA is zero, the user is placed 
in OUTPUT WAIT status. if ALPHA does not 
contain zero, control is immediately returned to 
ALPHA. 


To read a line: 

As supervisor entry: 


TSX RED L I N, 4 

PZE CONSOL 
PZE LOC, , ' n ' 
ALPHA OPN EMPTY 

normal return 


(TIA =HREDL I N) 


REDLIN will move n words from the designated console's 
input buffer to core beginning at location LOC. 
If the move was successful, the AC is zero. 


CONSOL If CONSOL is '(HOME)', the line will be. moved 
from the home input buffers. If the designated 
console is not attached, no action is taken and 
the normal return is taken with the AC non-zero. 

ALPHA If the designated console's input buffers are 
empty, and ALPHA is zero, the program is put 
into INPUT WAIT status. If the buffers are 
empty and ALPHA is not zero, control is returned 
immediately to ALPHA. 


To create a slave: 

As supervisor entry: 

TSX SLAVE, 4 (TIA =HS LAVE ) 

PZE CONSOL 
PZE MODE 
normal return 

CONSOL If the designated console is attached, it is 
made a slave according to MODE and normal return 
is made with AC zero. If it is not attached, no 
action is taken and the normal return is taken 
with non-zero AC. If CONSOL is '(HOME)', this 
call is ignored and AC is zero. 

MODE There are three distinct slave modes (11,00,10) 
providing eight combinations for any single 
console. The word at MODE is interpreted as 

three pairs of letters. If any of the pairs is 

recognized, the console is made to slave 

accordingly. If MODE does not contain a 

recognizable pair, the console is unslaved. 
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To set the character mode: 

As supervisor entry: 

TSX SET, 4 (TIA =HSET6 or =HSET12) 

PZE CONSOL 

SET6 sets the designated console in 6-bit mode. 

SET12 sets the designated console in 12-bit mode. They 
both reset the input buffer. 

If the designated console is '(HOME)', the user's 
console is mode-set. if the designated console 
is not attached, return is made with non-zero 
AC; otherwise, the AC is zero. 
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Identi f ication 

MAD/ FORTRAN on-line input compatibility 
( CSH ) / .READ/ .READL/ .LOOK/ .SCRDS 

Purpose 

MAD and FORTRAN on-line input statements compile as calling 
sequences to library subroutines. These subroutines use the 
console as the input device instead of the card reader. A 
data list and format statement are required. 

Usage 


MAD: READ FORMAT FMT / LIST 

FAP : TSX .READ/4 or TSX . READ L/ 4 

STR FMT/ /DIR or STR SYMTB/ D I R/ FMT 

OPS 

STR LIST// END LST 
OPS 

STR 0 


J 




FORTRAN: READ FMT/ LIST 

FAP: TSX ( CSH ) / 4 

P2E FMT/ /SWITCH 
OPS 

STQ LIST/t 
OPS 

TSX ( RTN ) / 4 


MAD: LOOK AT FORMAT FMT, LIST 

FAP: TSX .LOOK/4 

STR FMT, /DIR or STR SYMTB, D I R, FMT 
OPS 

STR LIST, /END LST 
OPS 

STR 0 

FAP: TSX . SCRDS, 4 

P2E BUF , , ' n 1 

.READ and (CSH) read lines from the console 
according to the format FMT and LIST. 

SWITCH if non-zero indicates that the format is 
enclosed in parentheses and stored forward. 

OPS may be indexing or other instructions. 

LIST is the beginning location of the LIST. 

ENDLST is the final location of the LIST. 
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DIR if zero the format is stored forwards. If 
1/ the format is stored backwards. 

SYMTB in a MAD call refers to the start (bottom) 
of the symbol table for this routine. 

BUF is the first (lowest) location of an array 
into which data will be read. 

n is an integer indicating the number of 
words to be read into the array BUF. 

•LOOK reads one line from the console according 
to the format specified by FMT. The next 
time a read statement is encountered, the 
same input will be processed. If more than 
one line of input is requested by the 
forma t , the same line will be used. 

. SCRDS reads a line from the console and stores 

the number of words requested into the 
buffer. 
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MAD and FORTRAN on-line output statements compile as calling 
sequences to library subroutines. These subroutines use the 
console as the output device instead of the printer. 


Maas ? 



MAD: PRINT FORMAT FMT, LIST FAP : 

PRINT ONLINE FORMAT FMT, LIST 

FAP: TSX .PRINT, 4 or TSX 

STR FMT, ,D I R or STR 

OPS 

STR L I ST, , ENDLST 
OPS 

STR 0 

FORTRAN: PRINT FMT, LIST 

FAP: TSX ( SPH ) , 4 

STR FMT,, SWITCH 
OPS 

LDQ L I ST, t 

STR 

OPS 

TSX (FI L) , 4 

FAP: TSX . SPRNT, 4 

PZE BUF, , ' n ' 


TSX .PRINT, 4 
TSX . COMNT, 4 
. COMNT, 4 
SYMTB, D I R, FMT 


(SPH) and (SPHM) are synonymous. 

.PRINT and .COMNT are synonymous. 

.PRINT and (SPH) type on the console the output as 

requested by the format FMT and LIST. The 

maximum line length is 22 words. 

SWITCH if non zero indicates that the format is 

stored forward. 

SYMTB in a MAD call refers to the start (bottom) of 
the symbol table for this routine. 

OPS may be any indexing instructions. 

L I S T ( , t ) is the beginning location of the list. 
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ENDLST is the final location of the list. 

DIR if zero, the format is stored forwards. If 1, 
the format is stored backwards. If anything 
else, a symbol table is implied. See MAD 
manual for deta i Is. 

BUF is the first (lowest) location of an array 
containing BCD information. 

n is the number of words in the array BUF. 
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I dent i f i cat i on 

Print a comment 
. PCOMT 

Purpose 

To print a comment from a MAD or FAP program on the user's 
console without a format statement. 

Usage 


MAD: PRINT COMMENT $MESS AGE$ 


FAP 

: TSX 

$ .PCOMT 

,4 



TXH 

'n' 




BCI 

' n ' /MESSAGE 


MESSAGE 

i s a si 

:ring of 

no more than 

132 Hollerith 


characters. The 

characters may 

not include 


dol 1 ar 

s i gns . 



n 

is the 

number of 

BCD words to be 

pr i nted. 
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Identification 

Print variables without format 
. PRS LT/ .PRBCD, . PROCT 

Purpose 

To print a list of variables on the user's console from a 
MAD or FAP program without specifying a format statement. 

Reference 


MAD Manual, Chapter 11/ Section 2.16 


Usage 


MAD: PRINT RESULTS list 

PRINT BCD RESULTS 1 ist 
PRINT OCTAL results list 


FAP: 


TSX $ . PRS LT, 4 (or .PRBCD or .PROCT) 
TXH SYMTB 
TXH A 

TIX LIST1//LISTN 
TXH 0 


SYMTB 


refers to the start (bottom) of the symbol 
table for this routine. 


A 

LI ST1 
LISTN 


refers to a single element. 

refers to the block of data. 

refers to the end of a block of data. 


TXH 0 marks the end of the list. 


The values of the variables designated by the 
list are printed on the user's console 
preceded by the corresponding variable name 
and an equal sign, e.g./ 

X = -12.4 

Blocks are labeled as such and are printed 
using a block format. Elements of three 
and higher dimensions will be labeled with 
the equivalent linear subscript. If dummy 
variables are included, the specific values 
assigned to such variables and expressions 
during execution will be preceded by '...'. 
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PRINT RESULTS (.PRSLT) causes the output to be 
numeric (that is, integer or floating 
point). 

PRINT BCD RESULTS (.PRBCD) causes the output to 
be printed as BCD information. 


PRINT OCTAL RESULTS ( .PROCT) causes the output to 
be printed as octal information. 
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Identification 

Read without list or format 
.RDATA / . RPDTA 

Purpose 


To read data from the console without specifying a list or a 
format statement. The data items are identified by their 
variable names as they are typed. The data may be read and 
printed with one statement. 


Reference 


MAD Manual , Chapter I I, Section 2.16 and 1.1 


MAD: 

READ 

DATA 

FAP : 

TSX 

$ . RDATA, 4 


TXH 

SYMTB 

MAD: 

READ 

AND PRINT 

FAP: 

TSX 

$. RPDTA, 4 


TXH 

SYMTB 


DATA 


SYMTB is the start (bottom) of the symbol table for 
this routine 


READ DATA reads information from lines typed on 
the user's console. The values to be read and 
the variable names are typed in a sequence of 
fields of the following form 

VI = nl, M2 = n2, , Vk = nk * 

where the V are variable names and the ni are 
the corresponding values. Reading is 

continued from line to line until the 
terminating mark '*' is encountered. 

READ AND PRINT DATA reads the data as explained 
above, and then immediately prints it out. 

In case of an input error, a message is 
printed on the user's console. Included in 
this message are the type of input error, the 
line in which the error occurred, the column 
number in which the error was found, and the 
recovery procedure. If the user wishes, he 
may retype the offending line and all 
succeeding ones, in order to continue. 
Otherwise, he may terminate his program by the 
'QUIT' signal. He may then use the PM or any 
other debugging command. 
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Identi fi cation 


Unbuffered disk string read and write 
DSKDMP, . DUMP/ . LOAD/ DSKLOD 

purpo se 

To write or read a continuous block of core on (from) the 
disk as a file. These routines are usually used for large 
blocks of core/ or short files. 

Usefie 

Two routines are available as supervisor entries and library 
entries. An additional routine is available in the library 
which may be called by MAD and Fortran programs. 

To write a file on the disk: 

Supervisor and library entry: 

TSX .DUMP/4 optionaKTIA =H.DUMP) 

OPN FILNAM 
PZE LOC/ / ' n 1 

OPN establishes the mode of the file; PZE is 
temporary/ PON is permanent/ PTW is Rl/ PTH is 
R2 . 

FILNAM refers to the file name which will be placed 
in the current file directory, deleting any 
older file of the same name. 

LOC is the initial location from which n words 
will be written on the disk. 

To read a file: 

Supervisor and library entry: 

TSX .LOAD/4 optional (TIA =H.L0AD) 

PZE FILNAM 
PZE LOC, , 1 n ' 

SLW M. 

n is the number of words to be read. It may be 
larger than the actual file size with the 
following restriction: LOC+n-1 must be less 
than the memory bound. FSTAT may be used to 
estimate n. 

M will contain the number of words actually 
loaded, as a full word integer. 



PAGE 2 


CTSS PROGRAMMER'S GUIDE 


Section AG . 2 . 01 


Corresponding library subroutine: 

MAD: EXECUTE DSKDMP. ( F I LNAM, F I RST, N ) 

EXECUTE DSKLOD. ( F I LNAM, F I RST, N ) 
M = DSKLOD. ( F I LNAM, F I RST, N ) 
FORTRAN: CALL DSKLOD ( F I LNAM, F I RST, N ) 

CALL DSKDMP ( F I LNAM, F I RST, N ) 

A = DSKLOD ( F I LNAM, F I RST, N) 


Core will be loaded or dumped from FIRST-n+1 
through FIRST. If the number of words ,m, in 
the file is less than n, the file will load 
into the block of core through FIRST-n+m. 
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I dent i f i cation 
Buffered disk input 

SEEK, .SEEK, .REAUK, ENDRD, . ENDRD, BREAD, VREAD, DREAD 
Purpose 

To provide the facility to read fixed length, string or 
line-marked disk files in the buffered mode by calls from 
FAP, MAD or FORTRAN programs. Records may be converted 
according to a format statement or may be transmitted 
without conversion. 

Method 

Disk files to be read must be located in the current file 
directory, the hardware must be set in motion to locate the 
first track of the file, a buffer must be assigned to the 
file and the tracks must be read to fill up the buffers. 
All of this initial activity is accomplished by the user's 
call to GEEK in which he may specify buffer locations. If, 
however, the user doesn't care to specify a buffer, SEEK 
will assign available space by extending the memory bound. 

Reading is accomplished by moving logical records out of the 
buffers into working core. When a buffer becomes empty, the 
supervisor fills it by reading the next track of the file 
into it. After sufficient data has been read from a file, 
the user may release the buffer and put the file in inactive 
status by a call to ENDRD. 

Res tr i ctions 

The library subroutines maintain a list of active files and 
assigned buffers. There may be no more than 10 active files 
and no more than 10 automatically assigned buffers. 

Reading by calls to the supervisor entries instead of the 
library subroutines means that buffers are not automatically 
assigned and errors cause execution of supervisor error 
procedures rather than the library error procedures. 

kS-agg 

To open a file: 

as supervisor or library entry: 

TSX .SEEK, 4 optional C T I A =H.SEEK) 

P2E FILNAM 
P£E BUF 1 

as library subroutine: 

FAP, MAD, or FORTRAN, 
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EXECUTE SEEK. ( F I LNAM, -BUF 1- ) 

BUF1 is initial location of 432 word block of core 
to be used as buffer. If BUF1 is not 
specified to the library subroutine/ a buffer 
will be assigned by extending the memory bound 
if core space permits. If no buffer space is 
available/ the library error procedure will be 
i ni t i ated. 

SEEK calls SRCH which assigns a buffer if needed 
and maintains an active file table and buffer 
assignment table. 

.SEEK does not call SRCH. 

To read a record: 

as supervisor or library entry: 

TSX .READK/4 optional C T I A =H . READK) 
P2E FI LNAM 
P2E LOC/t/n 
P2E E0F 


EOF SLW WC 

n words will be moved from the current buffer 
associated with F I LNAM and stored in a block 
of core beginning at location LOC. n may be 
larger than the actual file size but LOC+n-1 
must be less than the memory bound. 

t of non zero means skip n words without 
transmi ss i on. 

EOF If an attempt is made to read beyond the last 
word of the file FI LNAM/ control is 
transferred to location EOF. 

WC upon end of file return/ the AC will contain 
the number of words actually read/ as a full 
word i nteger . 

as a library subroutine: 

FAP or MAU 

EXECUTE BREAD. (F I LNAM/ LIST) 

EXECUTE DREAD. (FI LNAM, FORMAT, LIST) 
WC-VREAD. (FI LNAM, LIST) 

LIST is any mixture of single variables and block 
notation vectors locating the variables to be 
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read, if any. 

FORMAT is the location of the format by which the 
variables in LIST will be edited by (I0H). 

BREAD will read the n words specified by the LIST. 

n may be any size. No attention is paid to 
logical record breaks. If the input file is 
line-marked/ the line-marks will be moved as 
data words. 

DREAD reads logical records and edits them through 
(I0H). Each call to DREAD reads at least one 
logical record; however/ the format may 
require the reading of more than one logical 
record. If the file is line-marked/ the line 
marks delineate the logical records. If the 
file is not line-marked/ the logical records 
are 14 words. If fewer words are requested 
than are available in the record/ the excess 
of the record is lost. The format may specify 
the reading of more than one record; however/ 
if more words are requested from a specific 
record than are available within that record/ 
the library error procedure is initiated. 

VREAD will read one logical record. A logical 
record is either delineated by line-marks, set 
by SETVBF/ or assumed to be 14 words. The 
LIST may not exceed 22 words. If the LIST is 
longer than the logical record, the end of the 
list will be padded with blanks. If the LIST 
is shorter than the logical record, the 
remainder of the record will be lost. If the 
record was fixed length, the sign of WC will 
be minus. If the record was line-marked, WC 
will be positive. WC is a properly formatted 
integer but Fortran may have some difficulty 
because of the function naming conventions. 

To close an input file; 

as supervisor or library entry: 

TSX .ENDRD/4 optional (TIA =H . ENDRD ) 

P2E FILNAM 

as library subroutine: 

FAP, MAD, or FORTRAN 

EXECUTE ENDRD. (FI LNAM) 

ENDRD will delete the file from the active file 
table and release the buffer. 
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Identi fi cation 
Buffered Disk Output 

ASSIGN/ .AS l GN/ APPEND, . APEND, . WR I TE, F I LE, . F I LE, B-D- V-FWR I TE 
Purpose 

To provide the facility to write fixed length, string or 
line-marked disk files in the buffered mode. Records may be 
converted according to a format statement or they may be 
transmitted without conversion. 

Method 

The file must be defined and placed in an active file table 
and buffers must be assigned. This initialization is 
accomplished by ASSIGN. Writing then causes data to be 
moved from working core into the buffers. When a buffer is 
full, it is written on a track of the disk by the 
supervisor. A file in write status must be closed by FILE 
in order to assure that the last buffer has been written on 
the disk and the file name is entered into the file 
di rectory. 

Restrictions 

If the library subroutines are used, an active file table 
and assigned buffer table are maintained. There may be no 
more than 10 active files and 10 automatically assigned 
buffers. If the program is terminated by any terminal 
library routine, all files in write status will be properly 
closed. Any disk errors will initiate the library disk 
error procedures. 

If the supervisor entries (.ASSIGN, .APEND and .WRITE) are 
used and the program is terminated without going to .FILE, 
the file will be lost. Any disk errors initiate supervisor 
disk error procedures. 

USdAS 

To open a new f i le: 

as supervisor or library entry: 

TSX .ASIGN, 4 optional (TIA =H.ASIGN) 

UPN FILNAM 
P2E BUF 1 

as a library subroutine: 

FAP, MAD or FORTRAN 

EXECUTE ASSIGN. (FILNAM, -BUF1-) 
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UPN defines the mode: P2E is temporary, PON is 
permanent, PTW is Rl, PTH is R2. The library 
subroutine will define the mode as permanent. 

BUF1 is the initial location of a 432 word block of 
core to be used as a buffer. If BUF1 is 
absent from the library subroutine call, a 
buffer will be assigned by expanding the 
memory bound if core space permits. If no 
buffer space is available, the library error 
procedure will be initiated. 

ASSIGN calls SRCH which assigns a buffer if necessary 
and maintains an active file table and buffer 
assignment table. This allows terminal 

subroutines to close active files properly. 

.ASIGN does not call SRCH. 

To open an old file in order to add information: 
as supervisor or library entry: 

TSX . APEND, 4 optional (TIA =H. APEND) 

P2E FILNAM 
P2E BUF 1 

as a library subroutine: 

FAP, MAD or FORTRAN 

EXECUTE APPEND. (F I LNAM, -BUF1-) 

APPEND is the same as ASSIGN except the file name is 
located in the file directory and data to be 
added to the file will be written at the end 
of the exi sting file. 

To write a file: 

as supervisor or library entry: 

TSX .WRITE, 4 optional (TIA =H. WRITE) 
P2E FILNAM 
PIE LUC, , ' n 1 

n is the number of words to be written into file 
FILNAM beginning at location LOC. 
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as a library subroutine: 
'§ FAP, MAD or FORTRAN 


EXECUTE BWRITE. (FILNAM, LIST) 

EXECUTE DWRITE. ( F I LNAM, FORMAT, LIST) 

WC = VWRITE. (FILNAM, LIST) 

WC = FWRITE. (FILNAM, LIST) 

LIST is any mixture of single variables and block 
notation vectors locating the variables to be 
output. 

FORMAT is the format by which the variables in LIST 
will be edited through (I0H). 

BWRITE will write the n words specified by the LIST 

as a record without line marks. LIST may be 

any length. 

DWRITE will write the n words specified by LIST as a 
line-marked record after they have been edited 
by ( I OH ) . (3 .LE. n . LE. 22). If n .L. 3, 

blanks will be filled in until the record is 3 
words long. If the combination of FORMAT and 
LIST specify a line longer than 22 words, 
* (I0H) will type an error message and then call 

RECOUP. 

VWRITE will write the n words specified by LIST as a 

line-marked record. 3 .LE. n .LE. 22 (same 

convention as DWRITE). WC will contain an 
integer equal to the number of words written 
(not including the line-mark). The actual 
record length is n+1. 

FWRITE will write a fixed length record without 
line-marks. If the LIST is shorter than the 
fixed length, blanks will be filled in. If 
the LIST is longer than the fixed length, only 
the first words are written and the excess is 
lost. The fixed length is assumed to be 14, 
unless set by SETVB(F). WC will contain an 
integer equal to the number of words written, 
the sign will be minus. 

WC when WC is returned, it is the proper integer 
format for the language of the calling 
program. Fortran, however may have some 
difficulty as a result of the mode of the 
function convention. Fortran users should 
equivalence WC with an integer variable. 
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To close an output file: 

as supervisor or library entry: 

TSX . F I LE , 4 optional (TIA =H.FILE) 

P2E FILNAM 

as a library subroutine: 

F AP/ MAD / or FORTRAN 

EXECUTE FILE. (FILNAM) 

FILE will cause any active buffers to be written on 
the disk/ FILNAM will be entered into the 
current file directory/ the buffers will be 
set free, and the file removed from active 
status. if the library subroutines have been 
used to write the file/ a call to any terminal 
subroutine (EXIT/ DUMP/ etc.) will cause the 
calling of FILE for all active files. 

.FILE should be used if the file was written by the 
.WRITE supervisor entry. .FILE is the same as 
FILE except for the safety feature in the 
terminal subroutines/ i.e. files written by 
.WRITE will be lost if not .FILE'd before EXIT 
is called. 
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Identification 

Addressable disk files 
. RELRW 

Purpose 

To allow disk files to be treated as addressable secondary 
memory. Relative locations within a disk file may be 
specified for reading or writing. 

To open an addressable file: 

As supervisor or library entry: 

TSX . RELRW, 4 optional (TIA =H . RELRW) 
PEE FI LN AM 
PEE BUF 1 

.RELRW will open an addressable file which may be 
read or written. If writing, the mode is 
permanent . 

BUF1 is the initial location of a buffer whose size 
should be at least 432 words. 

To read or write an addressable file: 


As supervisor or 

1 i brar y entry: 



TSX 

.READK, 4 

TSX 

.WRITE, 4 

PEE 

F 1 LNAM, , rel adr 



PEE 

LOC, , 'n' 



PEE 

EOF 



optional (TIA 

=H. READK) 

(TIA 

=H. WRITE) 


reladr is the relative location within the disk file 
where the reading or writing will begin. The 
first word is number 1. If reladr is outside 
the limit of the file, the normal end-of-file 
procedure will be followed for reading or the 
supervisor error procedure will be followed if 
wr i ti ng. 

LUC, , 1 n ' n words of core beginning at location LOC will 
be read from or written in the disk file 
F I LNAM. 

EOF Location to which control will be transferred 
upon encountering an end of file. 
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To close an addressable disk file: 

As supervisor or library entry: 

TSX . ENDRD, 4 optionaKTIA =H. ENDRD) 

or TSX . F I LE/ 4 optionaKTIA =H .FILE) 

.ENDRD and .FILE are i nterchangab 1 e in the relative 
read-wri te mode. Write files not closed by 
one of these calls will be lost. 
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I denti f i cation 

Set the length of fixed length records 
SETVBF, SETVB 

P u r p le 

Records which are read or written by FWRITE or VREAD may be 
fixed length. The normal fixed length is 14 words. If a 
different length is desired, SETVBF may be used to specify 
the length. 

As a library subroutine: 

MAD, FAP, or FORTRAN 
B = SETVBF. (N) 

SETVBF and SETVB are synonymous. Both names are 
provided because of the Fortran function 
naming convention. 

N is (location of) the number of words to be 


record length. 


by 

FWRITE 

22. 

If N 

22. 


the 

f i xed 
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I dent i f i cation 

Service to library disk routines 

SRCH/ BLK, F LK, ENDF / CLOUT 

Purpose 

service routines are available to the library disk 

subroutines to assign buffers, find files, maintain the 

active file and buffer tables, and close out files. 

USfl gfi 

To search active file table: 

TSX SRCH, 4 

P2E FI LNAM 

not found 
found 

not found return means that F I LNAM was not found in the 
active file tab 1 e. 

found returns with the status of F I LNAM in the 
address of the AC and the buffer number (1-10) 
in the decrement of the AC. If the file is not 
using an assigned buffer, the buffer number is 
zero. Write status is 1; read status is 2. 

To ass i gn a buffer : 

TSX BLK, 4 

error return 
normal return 

BLK searches the buffer assignment table. If 
there are no free buffers and there are fewer 
than 10 assigned buffers, an attempt is made 
to extend the memory bound. 

error return is taken if there are already 10 
buffers assigned or the attempt to extend the 
memory bound was unsuccessful. 

normal return is taken with the address of the buffer 
in the address of the AC and the number of the 
buffer (1-10) in the decrement of the AC. 
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To enter a file in the active file table: 

TSX F LK ,4 
PEE FILNAM 
PEE status,/ number 
error return 
normal return 

status is 1 if writing, 2 if reading. The status 
word is stored in the first free space in the 
acti ve file table. 

number is the buffer number. If number is non-zero, 
a pointer to the file in the active file table 
is placed in the assigned buffer table. 

error return is taken if there are 10 active files 
a 1 ready. 

To close one file: 

TSX ENDF,4 
PEE FILNAM 

FILNAM is closed by either . ENDRD or .FILE, the 
buffer is free, and the file is removed from 
the acti ve table. 

To close all files: 

TSX CLOUT, 4 

All the files in the library's active file 
table are closed by calls to either .ENDRD for 
the read files or .FILE for the write files. 
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Identif i cation 

Generate file of zeros 
.CLEAR 


Purpose 

To create a new file which contains n zeros. 

As supervisor entry: 


TSX .CLEAR/ 4 (TIA =H. CLEAR) 

OPN FI LNAM/, 'n' 

.CLEAR will create a file of the name specified in 
F I LNAM which will contain n zeros. The 
opening and closing of the file are 
accomplished by .CLEAR so that .ASIGN and 
.FILE should not be called. 

OPN specifies the mode of the file: PZE is 
temporary/ PON is permanent/ PTW is Rl/ PTH is 
R2 . 
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I den t i f i cat i on 
Input and output 

OPEN / BUFFER / RDFI LE,WRFI LE / TRF I LE / FCHECK / CLOSE / SETPRI 
Purpose 

Files may be opened on any I/O storage device for reading, 
writing or reading and writing. A buffer may be assigned if 
needed and priorities may be set for different files. 

Me t hod 

It is assumed that the user is familiar with section AD. 2 
and AG. 4.06 of this manual. In order to read or write a 
file, the file must first be opened and in most cases a 
buffer should be assigned. Calls to RDFILE or WRFILE 
initiate the I/O for a relative location within the file. 
The actual data transmission is not completed upon return 
from the call. A subsequent RDFILE, WRFILE, FCHECK, or 
CLOSE is necessary to complete the data transmission and I/O 
error checking. All calling sequences will accept the two 
extra arguments for the error procedure. Any arguments 
which are not pertinent may be specified as -0. 

Usage 

OPEN: 


OPEN. ( $STATUS$,$ NAME1$,$ NAME 2 $ , MOD E, D EV I CE ) 


STATUS may be ' R * for read, 'W* for write or 'RW' for 
read-write. (justification is not 

s i gn i f i can t ) . 


MODE specifies the mode of a new file to be created 
and may be the inclusive logical or of any of 
the following octal values. If MODE is not 
specified, a permanent file will be created. 

000 - Permanent 

001 - Temporary 

002 - Secondary 
004 - Read-on 1 y 
010 - Wr i te-on 1 y 
020 - Pr ivate 
040 - Linkable 
100 - Protected 

DEVICE is pertinent only when creating a new file and 
it specifies which I/O device is desired. If 
DEVICE is zero or not specified, the system 
will assign a device. 
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1 - Low speed drum 

2 - disk 

3 - Tape 

Error codes: 

03. File is already in active status 

04. More than ten active files 

05. $STATUS$ is illegal 

06. 'LINKED' f i le not found 

07. File to which link is made is not 'LINKABLE' 

08. File in 'PRIVATE' mode 

09. Attempt to write a 'READ-ONLY' file 

10. Attempt to read a 'WRITE-ONLY' file 

11. Machine or System error 

12. File not found in U.F.D. 

13. Illegal device specified 

14. No space allotted for this device 

15. Space exhausted for this device 

16. File currently being restored from tape 

17. Input/Output error, see AG. 4. 06 

Assign a buffer: 

BUFFER. ($ NAME1$,$ NAME2$, BUF( N) . . . N) 

BUFFER In general a buffer should be assigned to an 
open file for reading or writing. 

BUF The buffer space should be specified in block 
notation as the beginning location of the 
buffer and the size. The size must be large 
enough to accomodate a physical record from 
the I/O device. 

N is the buffer size and 432 seems to be the 
going size. 

Error codes: 

03. File is not an active file 

04. previous I/O out of bounds (membnd changed) 

05. Buffer too small 

06. Input/Output error, see AG. 4. 06 

Set priority: 

SETPRI .( PRIOR) 

SETPRI is used to assign priorities to certain tasks 
which would otherwise be processed in the 
order in which they were received. When files 
are opened for reading and/or writing, they 
are assigned the priority set by the last call 
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to SETPRI. If there was no previous call to 
SETPRI, all files will be treated with equal 
priority. 

PRIOR is an integer from 1 to 7. The higher the 
value the lower the priority. 

Error codes: 

Standard error codes. See section 4.06 


Read : 

RDF I LE . ( $ NAME1$,$ NAME2$ , REL LOC, A( N ) . . . N, EOF, EOFCT) 

RDF I LE initiates the I/O necessary to move N words of 
data into location A(N) through A(l) from file 
NAME1 NAME2 . 

RELLOC specifies the initial location within the file 
from which reading is to begin. If RELLOC is 
zero, reading continues from the word 
following the last word read from the file. 
On the first call to RDFILE either 0 or 1 
specifies the first word. Note that in a file 
which is open for reading and writing, there 
are two separate pointers Ci.e., the last word 
read and the last word written). 

EOF is the location to which control will be 

transferred if the end of the file is 

encountered before N words are available to 
transmit into A. The words have not actually 

been transmitted to A so that FCHECK or CLOSE 

is necessary if data from A is to be used. 
The file is not closed by encountering an end 
of file. 

EOFCT is an integer variable which will contain the 
number of words to be transmitted by the call 
to RDFILE when the end of file was 
encountered. 

Error codes: 

03. File is not an active file 

04. File is not in read status 

05. No buffer assigned to this file 

06. Previous I/O out of bounds (membnd changed) 

07. Input/Output error, see AG. 4. 06 
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Write: 

WRF I LE . ( $ NAME1$^$ NAME2$ , RELLOC, A ( N ) . . . N, EOF, EOFCT ) 

WRFILE Initiates the I/O necessary to move N words 
from the array A(N) thru A(l) into the file 
NAME1 NAME2 . 

RELLOC is the relative location within the file where 
writing is to begin. If RELLOC is zero, 
writing will begin after the last word wr i tten 
in the file. If RELLOC is zero on the first 
call, writing will begin at the location 
following the last word of the file. RELLOC 
may not be larger than the current length of 
the file. 

EOF Is the location to which control will be 
transferred if the N words to be written would 
have to be written through the end of file 
(i.e., if part of the record could be 
contained within the file and the other part 
would extend to outside the file). This does 
not occur when appending to the file with a 
RELLOC of zero where entire records are placed 
at the end of the file. 

EOFCT is an integer variable into which the I/O 
system will store the number of words actually 
to be written when control was transferred to 
EOF. An FCHECK is necessary as with any 
WRFILE. 

Error codes: 

03. File is not an active file 

04. File is not in write status 

05. No buffer assigned to this file 

06. Allotted space exhausted for this device 

07. Previous I/O out of bounds (membnd changed) 

08. Input/Output error, see AG. 4. 06 

T runcate : 

TRF I LE . ( $ NAME1$,$ NAME2$, RELLOC) 

TRFILE The file NAME1 NAME2, which was previously 
opened for writing, will be truncated (i.e., 
cut-off) immediately before the relative 
location RELLOC. If RELLOC is less than the 
read or write pointers, they will be reset to 
their original places, (i.e., the read to the 
first word of the file and the write to after 
the last word of the file). 
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Error codes: 

03. File is not an active file 

04. File is not in write status 

03. No buffer assigned to this file 

06. Previous I/O out of bounds (membnd changed) 

07. RELLOC larger than file length 

08. Input/Output error, see AG. 4. 06 


Check: 


FCHECK. ( $ NAME1$, $ NAME2 $/ FINISH) 

FCHECK is used to check to see if a previous read or 
write of a specific file has been completed 
and checked for errors. Note that RDFILE, 
WRFILE / TRFILE, and CLOSE incorporate an 
automatic FCHECK at the beginning so that if 
FCHECK is not called explicitly/ any I/O 
errors are detected one call later than the 
call that caused the error. 

Error codes: 

03. File is not an active file 

04. Previous I/O out of bounds (membnd changed) 

05. Input/Output error/ see AG. 4. 06 


C 1 ose : 

CLOSE. ($ NAMEl$/-$ NAME2 $- ) 

CLOSE is used to close an active file and return it 
to inactive status. CLOSE incorporates an 
FCHECK for the last I/O call and initiates and 
FCHECKs the I/O necessary to empty any waiting 
output buffer. 

NAME1 may be 'ALL' and NAME2 not specified for all 
active files to be closed. 

Error codes: 

03. File is not an active file 

04. Previous I/O out of bounds (membnd changed) 

05. Input/Output error/ see AG. 4. 06 

06. Machine or System error 
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Identification 

Load a file into a free area of core 
LUFI L 

Purpose 

To load a file into a free area of core/ and then pass 
control to a specified function/ giving information as to 
where the file has been loaded and how long it is. 

U sa ge 


TSX 

LDFI L/4 

PZE 

=H NAME 1 

PZE 

=H NAME 2 

PZE 

FUNCT 

- PZE 

ARG1 - 

-PZE 

ARG2 - 


MAD: LDFIL. ($ NAME1$ NAME 2$/ FUNCT. , -ARG1-, -ARG2-) 

LDFIL loads the file NAM E 1 NAME 2 and calls FUNCT 
with the following call 

FAP: TSX FUNCT/ 4 

PZE LQDAD 

- PZE ARG1 - 

- PZE ARG2 - 

MAD: FUNCT. ( LODAD, -ARG1-, -ARG2-) 

LUDAD contains the exact word count (WC/ as an 
integer) of the file NAM El NAME 2 . The file is 
loaded into locations LUDAD+ 1/ . . . / LODAD+WC . 

ARG1 ARG2 are optional arguments which LDFIL will 
transmit, if present, to FUNCT. 

A return from FUNCT will automatically mean a 
return to the program which called LDFIL with 

all registers except index register 4 
preserved. 

LDFIL uses FRER, FRET and COLT in addition to 
the l/U system routines. 


If sufficient space is not available to load 
NAM El NAME2, LDFIL will cause a comment to be 
printed (by FRER) and call EXIT. 
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I dent I f i cat i on 

Change the mode or the name of a disk file. 

CHMODE, RENAME, .RENAM 

Purpose 

To be able to change the mode or the name of a disk file. 
Usage 


To change mode: 
as 1 ibrary 

subrout i ne : 

FAP: 

TSX 

CHMODE, 4 


PEE 

FI LNAM 


PEE 

MODE 

FORTRAN: 

A = 

CHMODE (FI LNAM, MODE) 

MAD: 

A = 

CHMODE. (FI LNAM, MODE) 


MODE is 0 for temporary, 1 for permanent, 2 for 
read only Rl, 3 for read only R2. 

A will be zero if successful or will contain the 
disk error code if the file cannot be found or 
i s R2 read-onl y . 

To change name and/or mode: 

as supervisor or library entry: 

FAP : TSX .RENAM, 4 optional (TIA =H. RENAM) 

OPN NEWNAM, , F I LNAM 


To change name: 

as library subroutine: 

MAD: A = RENAME. (NEWNAM, FI LNAM) 

FORTRAN: A = RENAME (NEWNAM, FI LNAM) 

.RENAM replaces in the current file directory the 
file name specified by F I LNAM by the new name 
located at NEWNAM. R2 read only files can not 
be changed in any way by this entry. All 

other classes may be changed by .RENAM. The 

standard supervisor error procedure may be 
fol 1 owed. 

OPN specifies the mode of NEWNAM. PEE is 
temporary, PON is permanent, PTW is Rl, and 
PTH is R2 . 
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RENAME calls .RENAM so that the AC or A will be zero 
if successful or will contain the error code 
if unsuccessful. Any deletable files named 
NEWNAM will be deleted (except if NEWNAM = 
FILNAM). The old file is given the new name 
and the mode is unchanged. 
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I dent i f i ca t i on 

Delete file from file directory 

DELETE, ERASE, . DLETE, .ERASE 

Purpose 

To delete a file name from a file directory and either make 

the tracks available for some other use or leave the tracks 

in the "in use" state until the next system loading. 

Usage 

To delete a file: 

as supervisor or library entry: 

FAP: TSX .DLETE, 4 optional (TIA =H. DLETE) 

PZE FILNAM 

as library subroutine: 

MAD: EXECUTE DE LETE . ( F I LNAM ) or A = D ELETE . ( F I LNAM ) 

FORTRAN: CALL DELETE (FILNAM) or A = DELETE (FILNAM) 

.DLETE does not require buffer space but it does read 
each track of the file specified in order to 
delete it and update the track usage table. 

The FILNAM is removed from the current file 
directory and the tracks are made available 
for other use. Read only R1 and R2 files may 
not be deleted by this routine. Any error 
will invoke the supervisor error procedure. 

DELETE calls .DLETE. If FILNAM is R1 read-only mode, 
a message will be typed asking if the file 
should really be deleted. The user must type 
yes or no and a carriage return. R2 mode 
files may not be deleted. 

Upon return, if the file is not deleted, the 
AC and A will contain a 1, otherwise the AC 
and A wi 1 1 be zero. 

To erase just the name: 

as supervisor or library entry: 

TSX .ERASE, 4 optional (TIA =H. ERASE) 

PZE FILNAM 

as library subroutine: 

MAD: EXECUTE ERASE .( F I LNAM ) or A = ERAS E . ( F I LNAM ) 

FORTRAN: CALL ERAS E ( F I LNAM ) or A = ERAS E ( F I LNAM ) 
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ERASE is the same as DELETE (.ERASE = . D LETE ) except 
that the tracks are not made available for 
other use and the user's track count is not 
updated until the next time the disk is 
loaded. Note/ this description was true for 
the old file system but is no longer true. 
ERASE is no longer different from DELETE but 
the write-up remains for compatibility. 


I) 
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I dent i f i cat i o n 

Switch current file directory 

COMF I L, COMFL, TSSFIL, USRFIL 

Purpose 

To allow the user to switch between his file directory/ 

common file directories associated with his problem number/ 

or the system library file. 

Usage 

As supervisor or library entry: 

CAL N 

TSX COMF I L/ 4 optional (TIA =HC0MFIL) 

P2E BUSY 

N contains the integer of the common file 
directory desired. Zero is the user's file 
d i rectory . 

BUSY is the location to which control will be 
transferred if the requested file directory is 
busy. The logical AC will contain the problem 
number and the MQ/ the programmer number in 
BCD of the user currently using the requested 
file. Note/ this is no longer true but the 
calling sequence is preserved for 

compatibility. Control will always return to 
2/4. 

Note: temporary files in the current file 

directory are deleted by directory switching 
if the current file directory is not the 
user's file directory. All files in the 
current file directory are reset. 

As library subroutine: 

MAD: A = COMFL. (N) or EXECUTE COMFL. (N) 

FORTRAN: A = COMFL(N) or CALL COMFL(N) 

A is zero if switching has been performed or A 
will contain the programmer number of the user 
currently using the requested file directory. 
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To switch to the system library: 

As supervisor or library entry: 

TSX TSSFIL,4 optional (TIA =HTSSFIL) 

TSSFIL switches the user to the system library file 
directory. This directory is composed of 
links to certain files in the system file 
directory which are in read-only, protected 
mode. The track quota of the TSSFIL directory 
is 0, so that the user may not create files 
after a call to TSSFI L. 

TSX USRF I L, 4 optional (TIA =HUSRFIL) 

USRFIL switches from the system library file back to 
the current file directory. 

Note: the library entries, TSSFIL and USRFIL, 

may be called from MAD or Fortran programs. 

A call to TSSFIL causes all active files in the current file 
directory to be RESET (i.e., active write files are lost and 
temporary read files are deleted). 
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Identificatio n 

Query file status 
FSTAT , . FSTAT 

Pu rpose 

To obtain the mode and word count of a specified file. 
Usage 


As supervisor or library entry: 

TSX . FSTAT / 4 optional (TIA =H. FSTAT) 
PZ E FI LNAM 

As library subroutine: 

MAD: A = FSTAT. (FI LNAM) 

FORTRAN: A = FSTAT( F I LNAM) 

.FSTAT If the file is not found, the supervisor disk 
error procedure is initiated. 

Upon return from FSTAT, the AC or A will contain zero 
if the file was not found. Otherwise, it will 
contain a word of the form OPN WDCNT. 

OPN is the mode of the file, PZE is temporary, PON 
is permanent, PTW is Rl, PTH is R2. 

WDCNT (the address and tag) is the word count of the 

file. 
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I dent i f i ca t i on 

Get the name of next file 
GTNAM 

Purpose 

If a program creates an unknown number of files, assigns 
them sequential primary names, and uses them in a push down 
list, it is necessary to be able to determine the next 
available primary name. GTNAM performs the search for the 
next available name. 

Usage 

As library subroutine: 

FAP, MAD or FORTRAN 

A = GTNAM. ($bCLASS$) 

GTNAM searches for the first file which does not 
exist in the series of primary names ...001 
thru ...999 with secondary name CLASS; then 
tries to delete the following file, if any; 
and returns in A the first BCD primary name 
available in the series. 
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I dent i f i cat i o n 

Drop files from active status 

.RESET 

Purpose 

To remove all user's files in active status from the 

supervisor's list of active files. 

Usage 

As supervisor or library entry: 

TSX . RESET, 4 optional (TIA =H. RESET) 

.RESET will remove all the user's active files from 
the active status. All files in active write 
status will be lost. All temporary files in 
active read status will be deleted. This call 
will not remove the user's active files from 
the library subroutines' list of active files. 
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Identif i cation 

File status/ change name or mode, or delete 
CHFILE, DELFIL/ FSTATE/ STORGE 

Purpose 

With the new I/O system, as with the old, it is possible to 
change the mode or name of a file, to delete a file, or 
query the system about the status of a file. 

Usage 

Change: 

CHFI LE. ($0LDNM1$,$0LDNM2$, -NEWMQD-, -$NEWNM1$-, -$NEWNM2$-) 

0LDWM1 QLDNM2 is the name of the file which is to be 
changed (right adjusted, blank padded). This 
file may not be in active status at the time 
of the change. 

NEWMOD is the desired mode of the file. 

NEWNMl NEWNM2 is the desired name of the file. 

Error codes: 

03. Attempt to change M.F.D. or U.F.D. file 

04. File not found in U.F.D. 

05. 'LINKED' file not found 

06. File to which link is made is not 'LINKABLE* 

07. Attempt to change 'PRIVATE' file 

08. Attempt to change 'PROTECTED' file of another 
user 

00. Temporary file would overflow space allotted 
for device 

10. File already exists with name 'NEWNMl NEWNM2' 

11. Machine or System error 

12. File in active status 

Delete: 

DELF I L. ($ NAME 1$ , $ NAME2$ ) 

DELFIL will delete the file NAME1 NAME 2 from the file 
directory and the space is immediately 
available for use within the record quota. 

Error codes: 

03. File not found in U.F.D. 

04. 'LINKED' file not found 

05. file to which link is made is not 'LINKABLE' 

06. File is 'PROTECTED' 

07. Machine or System error 

08. File in active status 
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Status: 

ESTATE . ( $ NAME1$ , $ NAMF2 $ , A ( 8 ) . . . 8 ) 

Upon return, the array A will contain the following 
information as integers: 

A(8)= length of file in number of words 
A ( 7 ) = MODE of file 
A ( 6 ) = STATUS of file (1-4) 

A(5)= DEVICE on which file resided (1-3) 

A ( 4 ) = Address of next word to be read from file 
A ( 3 ) = Address of next word to he written into file 
A(2)= Date and time file was created or last 
modified, format of U.F.D. 

j A(l)= Date file was last referred to and 'AUTHOR' of 

file, format of U.F.D. 

j STATUS is 1 inactive 

t 2 open for reading 

3 open for writing 

4 open for reading and writing 

DEVICF is 1 Low speed drum 

2 Disk 

3 Tape 

Error codes: 

■' 03. File not found in U.F.D. 

04. 'LINKED' file not found 

;; 05. File to which link is made is not 'LINKABLE' 

Size: 

(J . STORGE. (DEVI CF, ALLOT, USED) 

STORGE may be used to determine the number of records 

1 1 allotted and used on a particular device by 

h the files of the current file directory, 

ALLOT and USED are integer variables which, upon 

return, will contain the number of records 
allotted and used, repectively. 

Error codes: 

03. Illegal DFVICF specified 

04. Machine or System error 
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I dent i f i cat i on 

Historic File System Error Procedure 
Purpose 

The historic supervisor disk control routine provided a 
standard error procedure as well as a handle by which the 
user may supply his own procedure. 

Usage 

Standard : 

If a disk error occurs and the user has not 
specified an error return, the supervisor will 
type: 

ILLEGAL CALL TO XXXXXX. NO ERROR RETURN SPECIFIED 

and then call DORMNT so that debugging tools may 
be used. 

User's option: 

The user may add another argument to the calling 
sequence of any disk supervisor or library entry, 
in which he specifies the location of his error 
routine. If the prefix of this argument is PEE, a 
diagnostic will be printed and control will be 
transferred to the specified location with an 
error code in the AC. if the prefix of the 
argument is MEE, the diagnostic will not be 
printed but otherwise action will be the same as 
P2E. The error codes are: 


Illegal calling sequence PEE 1 
Too many active files (.G. 10) PEE 2 
User not found in Master File Directory PEE 3 
Available space on module exhausted PEE 4 
File not found pg E 5 
Allotted track quota exhausted PEE 6 


The error code of 1, "Illegal calling Sequence" may result 
from any of the following error conditions: 

a. Illegal call to the .WRITE routine ; this occurs 
if the call to .WRITE references a file which is 
in active read status, or a file in relative 
read-write status where a relative address is not 
specified, or if a relative address is specified 
for a file not in relative read-write status or an 
HI mode file in relative read-write status. 

b. Illegal call to the .CLEAR routine; this occurs 
if the call references a file in active read 
status or relative read-write status. 
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c. Illegal call to the .FILE routine; this occurs if 
the call references a file in active read status. 

d. Illegal call to the .READK routine; this occurs 
if the call references a file not in active read 
status/ or if a relative address is specified for 
a file not in relative read-write status. 

e. Illegal call to the .ENDRD routine; this occurs 
if the call references a file in neither active 
read nor relative read-write status. 

f. Relative address too large for file; this occurs 
if an attempt is made to write into a relative 
address greater than the length of the file 
referred to. 

g. File word count zero; this occurs on a call to 

.DUMP with a word count of zero, or a call to 

.FILE where no words have been written; the disk 
routine is so organized that a file with a zero 
word count may not exist. 

h. Tried to rename read-only class 2. 

i. Attempt to delete file in read-only mode. 

j. File NAME1 NAME2 is not an active file; this 

occurs if a call to .WRITE/ .FILE/ .READK/ or 

.ENDRD references a file not in active status. 
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Identi f ication 

Library disk error procedure 
SETERR/ SNAP/ RECOUP 

Purpose 

The library disk subroutines provide a standard error 
procedure as well as handles by which the user may provide 
his own error procedure. 

Method 

The library disk subroutines use a common routine which 
maintains an active file table. If an unexpected error 
occurs/ the offended routine calls SNAP which prints an 
error message and calls RECOUP which in turn calls EXIT. 
EXIT is able by means of the active file table to properly 
FILE any active write files and save core so that the user 
may then use debug facilities. RECOUP and SETERR are 
provided so that the user may supply his own error 
procedure. 

u sag e 

SETERR: 

MAD: EXECUTE SETERR. ( -RETURN-/ -ERROR-) 

FORTRAN: CALL SETERR ( -N-/ -ERROR- ) 

FAP: TSX SETERR/4 

-P2E RETURN- 
-P2E ERROR- 

SETERR modifies SNAP so that if SNAP is called, control 
will be transferred according to RETURN without 
disturbing any machine conditions. 

RETURN is the error return location to which the 
library disk routines should transfer for 
unexpected errors. No message will be printed 
from SNAP. 

ERROR is the location in which the logical 
accumulator will be stored i.e., the error 
code from the disk routine. 

N Should be set by an ASSIGN statement in 
Fortran programs in order to provide the error 
return. 

If only one argument is provided to SETERR, it will be used 
as the error return argument. 

If no argument is provided to SETERR, the standard error 
procedure will be reinstated. 
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Every call to SETERR supercedes the previous one. 
RECOUP: 


CALL RECOUP (ERCODE, IR4,-IND-) 

RECOUP may be supplied by the user if he wishes to 
provide his own procedure. If no user RECOUP 
is provided, the library version of RECOUP 
merely calls EXIT. 

ERCODE contains the logical AC from the offended disk 
routine, or the error code from (I0H). 

Error codes: 

1 Illegal control character in format 
s tatement . 

2 Illegal character in data field. 

3 Illegal character encountered in octal input 
data . 

I R4 (decrement) contains the contents of index 
register 4 at the time of the call to SNAP. 
It should be used to reset index register 4 
before returning to the I/O routine. 

IND contains the contents of the sense indicators 
at the time of the error in the disk routine. 
This argument is not present in the call from 
( I0H) . 

Sense indicators contain (decrement) the return 
location if processing is to be continued. 


SNAP: 

The library disk subroutines normally supply SNAP 
as the error exit to the supervisor disk routines. 
The call i s, the refore, a TRA instead of a TSX and 
the AC contains the disk error code. 
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Identi f i cation 

End-of-file procedure for library subroutines 
EGFXIT, SETEOF , WRUCNT 

Purpose 

EUFXIT provides a common end-of-file procedure for all 
library subroutines which read tape or disk files. The user 
is supplied a handle whereby he may supply his own 
end-of-file procedure if he wishes. 

Method 

The standard library procedure is to call EOFXIT upon 
encountering an end-of-file. EOFXIT prints a message and 
calls EXIT. The user may call SETEOF before reading and 
thus modify EOFXIT to return to the user's eof procedure 
rather than calling EXIT. 

Usane 

EOFXIT: 

The library routines call EOFXIT by: 


TSX EOFX I T/ 4 
P2E F ILHAM 

EOFXIT prints the message "END OF FILE READING NAM El 
NAME2". It then calls EXIT/ unless it has been 
modified by SETEOF. 

sETEOF : 


TGX 

GETEUF/4 

-P£E 

EOF- 

-P2E 

F 1 LNMl- 

-P£E 

F l LNM2- 


MAD: EXECUTE SETEOF . ( -EOF-/ -F I LNM1-/ -F I LNM2-) 

FORTRAN: CALL GETE0F(-N-/ -FILNMl-/ -FILNM2-) 

sETEOF will modify EOFXIT to return to location EOF 
in the user's program if an end-of-file is 
encountered. If there are no arguments, the 
standard eof procedure is restored. Each call 
to GETEOF supercedes any previous call. 

EOF is the location of the user's end-of-file 
procedure. 

N must be set by an AGS I GN statement in Fortran 
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i .e. ASSIGN 1 TO N 
GO TO N, (1/2) 
1 ASSIGN 2 TO N 


2 eof procedure 

F I LNM1, F I LNM2 are the locations in which NAME1 and 
N AM E 2 , respectively/ will be stored by EOFXIT. 
If FILNM2 is missing/ the logical tape number 
will be stored in FILNM1. If both FILNM1 and 
FILNM2 are missing, a single argument will be 
assumed to be EOF or N. 


WRDCNT : 

FAP: TSX WRDCNT/ 4 or TSX WRDCNT, 4 

P2E LOC ST0 LOC 

MAD or FORTRAN: CALL WRDCNT (LOC) 

WRDCNT can be called only after an end of file was 
encountered by BREAD or VREAD. 

LOC will contain the number of words transmitted by 
BREAD as a right adjusted integer. If WRDCNT is 
called by a FORTRAN program, the integer will be 
in the decrement of LOC. 
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I dent i f i cat i on 
Terminal procedure. 

EXIT/ EXITM/ CLKOUT/ END JOB, DUMP, PDUMP 
Purpose 

To provide a common routine for the normal logical 
termination of all programs. The option is provided for 
placing the program in DORMNT status so that post mortem 
debugging may be used. 

Usage 

EXIT, CLKOUT and ENDJOB are synonomous. 


EXECUTE EXIT. 

EXECUTE CLKOUT. 

EXECUTE ENDJOB. 

END OF PROGRAM 
END OF FUNCTION 

The message "EXIT CALLED. PM MAY BE TAKEN" will be 
pr i nted. 


EXECUTE DUMP. 

EXECUTE PDUMP. 

The exit message will be printed with the name 
DUMP or PDUMP substitued for EXIT. 

Any of the above calls cause all active files as 
defined by library subroutines to be properly 
closed and then a transfer to DORMNT. 


EXECUTE EXITM. 

The message "EXITM CALLED. GOODBYE" will be 
printed; active files will not be closed; 
transfer will be to DEAD. 
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I den t i f icat i on 

Error Exit from Math Library Routines 
LDUMP 

Purpose 

LDUMP is a subprogram to which some library math routines 
transfer upon encountering an error. The version of LDUMP 
which is in the library is a call to EXIT / but the user may 
provide his own version of LDUMP to provide recovery action. 

Usage 

The calling sequence to LDUMP which is used by the math 
routines is 


FAP : 

CLA 

ARG1 



LDQ 

ARG2 



TSX 

LDUMP, 4 



PZE 

NAME 



TRA 

1 N 

TO REPEAT ROUTINE 


TRA 

OUT 

TO EXIT FROM ROUTINE 


IN LXD 

1 R4, 4 



TRA 

0,4 



OUT LXD 

1 R4,4 



TRA 

1/4 


ARG1 

conta i ns 

the first 

argument to the math 


library subprogram. 


ARG 2 

contains the second 

argument, i f any, to the 


math library routine 

• 

NAME 

conta i ns 
routine. 

the BCD 

name of the offending 

IN 

is the return of 2, 

4 which the programmer 


should use 

if he is 

writing his own LDUMP and 


wishes to 

repeat 

the offended subprogram 


after he has corrected the error. 


OUT is the return of 3,4 which the programmer 
should use if he wishes to return from the 
offended routine without repeating its 
calculations. 
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Identi f i cation 

Current I/O system error procedure 
I0DIAG, FERRTN, PRNTER 

There are three different ways that errors from the I/O 
system can be handled. First/ if the user does nothing/ the 
I/O system will print a standard message and call DORMNT. 
Second/ the user may call FERRTN to establish a standard 
error return for all I/O system errors. Third/ every call 
to the I/O system will accept two additional arguments which 
specify an error return and a location into which the error 
code will be stored. 

Usa&e 

Standard: 

If an error is encountered by the I/O system 
and the user has not supplied an error return/ 
the I/O system will type a standard message 
and call DORMNT so that debugging tools may be 
used. The typed message will include the 
information available from I0DIAG. 

Single return: 


OLDERR = FERRTN. (ERRLOC) 


FERRTN 

sets the standard 
be location ERRLOC 

I/O system error 

• 

return 

to 

ERRLOC 

is the 1 ocat i on to 
transferred if 

which control 
the I/O system 

shoul d 
detects 

be 

an 


error. Upon entry to ERRLOC/ index register 4 
will contain the value set by the call to the 
I/O system that caused the error to be 
detected. To continue execution by ignoring 
the I/O call/ transfer to 1, 4. To continue 
execution by repeating the I/O call, transfer 
to U/ 4. 

If ERRLOC is zero, the standard I/O error 
procedure will be reinstated. 

OLDERR Upon return from FERRTN, the AC will contain 
the previous setting of the system error 
return. Each call to FERRTN supercedes any 
previous call. 
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I nd i v i uual returns : 

Each call to the I/O system entries will 
accept two additional arguments at the end of 
the call. The first is the location to which 
control is to be transferred if an error is 
encountered by the I/O system. The second, if 
specified, is the location into which the 
error code will be placed by the I/O system. 

U i agnos tic: 

IOUIAG. (A(7)...7) 

IODIAG may be called to obtain specific information 
about the I/O system error. Upon return, the 
array A will contain the following 
information: 

A( 7) = Location of call causing the error 
A(6)- BCD name of entry resulting in error 
A(5) = Error code 

A( 4 ) = Input/Output error code (1-7) 

A( 3) = NAM El of file involved in error 
A(2)= N AH E 2 of file involved in error 
A(l)- Location of file sys tern where error was 
found (of no use to user) 

PRNTER. or PKNTER command 

PRINTER The routine PRwTER or the command PRNTER may 
be called after an error in the I/O system in 
order to print the information that is 
available from IODIAG. In other words, PRNTER 
is a small routine which calls IODIAG and 
formats and prints the information. 

Error codes: 

Standard error codes: 

There are a few standard error codes which may 
be returned from any of the I/O system calls. 

GUI. Illegal calling sequence or Protection 
violation 

UU2. Unauthorized use of priveleged call 
ldU. Error reading or writing U.P.D. or M.F.D. 
101. U.F.D. or M.F.D. not found. Machine 
error 
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Input/output error codes: 

In many of the write-ups of the calls to the 
I/O system/ one of the possible error codes is 
labeled Input/Output error. For the most part 
these errors are detected only after the I/O 
has been completed and will/ therefore, be 
reported one call late. The actual error may 
be diagnosed by the value of A(4) after a call 
to I0DIAG. 

1. Parity error reading or writing file 

2. Fatal error reading or writing file, cannot 
cont i nue 

3. Available space exhausted on this device 

4. Tape file not mounted or not available 
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I dent i f i cation 


Write BCD pseudo tape with format conversion 
.PUNCH, . PNCHL, .TAPWR, (SCH), (STH)/ (STHM) 

Purpose 


The MAD and 
compi 1 ed as 
subrout i nes 
calling the 


FORTRAN BCD tape and punch statements are 
calling sequences to library subroutines. These 
then simulate the writing of tape files by 
library disk routines. 


Usage 


MAD : 

PUNCH 

FORMAT FMT/ LIST 

FAP: TSX 

.PUNCH/ 4 


PUNCH 

ONLINE FORMAT FMT/ LIST 

TSX 

.PNCHL/ 4 


WRITE 

BCD TAPE N/ FMT/ LIST 

TSX 

.TAPWR/ 4 

FORTRAN: 

PUNCH 

FMT/ LIST 

TSX 

(SCH) /4 


WRITE 

OUTPUT TAPE N/ FMT/ LIST 

TSX 

( STH) / 4 

The FAP 

calling 

sequence compiled for MAD 

programs 

i s of the 


form: 


TSX 

.TAPWR, 4 

STR 

N 

STR 

FMT/ /DIR 

OPS 


STR 

L 1 ST/ / END 

OPS 


STR 

0 


The FAP calling sequence compiled for FORTRAN programs is of 
the form: 

CAL N 

TSX (STH), 4 
P2E FMT,, SWITCH 
OPS 

LDQ LIST 
STR SWT 
OPS 

TSX ( F I L) , 4 

.PUNCH/ .PNCHL/ and (SCH) create or append to a pseudo 
tape line-marked file named .TAPE. 3 

.TAPWR/ (STH)/ and (STHM) create or append to a pseudo 
tape line-marked file named .TAPE, 'n' 


N contains the number of the pseudo tape to be 
used (decrement for FORTRAN) 


OPS may be indexing instructions 
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SWITCH is zero if the format is stored backwards and 

non-zero if the format is stored forward. 

LIST // ENDLST are for standard list processing (see 
MOVE 1, 2, 3). 

DIR If zero, the format is stored forward. If 
one, the format is stored backward. 

SWT if zero with I format, the value is taken from 
the decrement of location LIST. If non zero 
with I format, the value is taken from the 
address of location LIST. 

(FIL) provides blank padding; with (SCH) to 80 
characters and with (STH) to 132 characters. 

Disk errors will evoke the standard library 
disk error procedure and format errors call 
RECOUP. 
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I de ntLfi c a .tL o p 

Read BCD pseudo tape with format conversion 
.TAPRD, (TSH) / (TSHM) 

Purpose 

MAD and FORTRAN BCD tape read statements compile as calling 
sequences to library subroutines which in turn call the 
library disk routines to read pseudo tape files from disk. 


MAD: READ BCD TAPE N, FMT/ 

FAP: 


TSX 

.TAPRD, 4 

STR 

N 

STR 

FMT, , D 1 R 

OPS 


STR 

LIST,, ENDLST 

OPS 


STR 

0 


LIST 


FORTRAN 


READ INPUT TAPE N, FMT/ 


CAL 

N 

TSX 

(TSH) ,4 

P2E 

FMT, , SW 

OPS 


STR 


STQ 

LIST 

OPS 


TSX 

( RTN) , 4 


LI ST 


(TSH) and (TSHM) are synonymous. 

(TSH), (TSHM), and .TAPRD read records from the disk 
file .TAPE, n according to the format and 
list. The file may be line-marked or fixed 
length of 14 words. 

N contains the tape number (decrement for 
(TSH) ) . 


OPS 

SWITCH 

DIR 

LIST./ENDLST 


may be indexing instructions. 

of non-zero indicates the format is stored 
forward. 

If zero, the format is stored forward. If 
one, the format is stored backward. 

are standard LIST processing (see MOVED. 
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I rlent i f I cat i on 

Read and write binary pseudo tape. 

(STB), (TSB), (WLR), ( RLR ) 

Purpose 

FORTRAN programs which use binary tape statements, may be 
compiled as background and run as foreground since the 
library subroutines will simulate the tapes as disk files. 

Restr i ct i ons 

The subroutine . RB I N called by binary tape statements in a 
MAD or MADTRAN translated program is not currently available 
i n the 1 i brary. 

Usage 

FORTRAN: WRITE TAPE N, LIST 


CAL 

N 

TSX 

(STB), 4 

OPS 


LDQ 

LIST 

STR 


OPS 


TSX 

( WLR ) , 4 


FORTRAN: READ TAPE N, LIST 

FAP: CAL N 

TSX (TSB), 4 

OPS 

STR 

STQ LIST 
OPS 

TSX (RLR), 4 

N contains in the decrement the number of pseudo 
tape. 

OPS may be indexing instructions. 

and (STB) read or write the number of words 
specified in the LIST from the pseudo tape 
file .TAPE, 'n' by calling BREAD or BWRITE. 


(TSB) 





(I 

[' 
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Identification 

Pseudo tapes; backspace, write end of file, rewind 
. BSF , . BSR, .EFT, . RWT, (BST), ( EFT) > CRWT) 

Pur pose 

MAD and FORTRAN programs which refer to tapes are assigned 
disk space which is used to simulate the tape. These pseudo 
tape files may then be referred to by the standard MAD and 
FORTRAN statements which compile as calling sequences to the 
appropriate library subroutines. These library subroutines 
then simulate the functions as far as possible on the pseudo 
tape f i 1 es . 

Restr i ctions 

The disk pseudo tape files may not be backspaced and 
therefore the backspacing subroutines do nothing but print a 
console message "BACKSPACE TAPE IGNORED". 




MAD: BACKSPACE FILE OF TAPE N 

BACKSPACE RECORD OF TAPE N 
END OF FILE TAPE N 
REWIND TAPE N 


MADTRN : 

FAP : 

FORTRAN: 


BACKSPACE N 
ENDFI LE N 
REWIND N 

TSX .BSF, 4 
TXH N 

BACKSPACE N 
END FILE N 
REWIND N 


or TSX .EFT, 4 or TSX .RWT, 4 


FAP: CAL N 


CAL N 


CAL N 


TSX (BST), 4 TSX (EFT), 4 TSX (RWT), 4 

.BSF and .BSR are synonymous and simply transfer 
to (BST). 


(BST) does nothing but print the console message 
"BACKSPACE TAPE IGNORED" and return. 

.EFT and (EFT) close the pseudo tape file .TAPE, 
'n' by calling the library subroutine FILE. 

•RWT and (RWT) close the pseudo tape file .TAPE. 
' n' if it is act i ve. 
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1 denti f i cation 

Program status 

DEAD, DORMNT, GET I LC, FNRTN 

Purpose 

To remove a program from active status and place it in dead 

or dormant status and to be able to know the location of the 

last call to DORMNT. 

Usage 

DEAD: 

as supervisor or library entry: 

TSX DEAD,4 optional CTIA =HDEAD) 

DEAD returns control to the supervisor and places 
the user in dead status. Machine conditions 
are not saved and memory bound is set to zero. 

DORMNT: as supervisor or library entry: 

TSX DORMNT, 4 optional (TIA =HD0RMNT ) 

DORMNT returns control to the supervisor and places 
the user in dormant status. Machine 
conditions, status, and memory bound are 
saved. If the START command is issued, control 
returns to 1,4. If a new program is read in, 
the machine conditions, status, and memory 
bound are overwritten. 

GETILC: as supervisor entry: 

TSX GETILC, 4 (TIA =HGET I LC ) 

Upon return, the AC will contain the value, of 
the instruction location counter at the time 
when the user last entered dormant status. 

FNRTN: as supervisor entry: 

TSX FNRTN, 4 (TIA =HFNRTN) 

FNRTN returns the user to dormant status and resets 
the user's instruction location counter to the 
value it had when he last entered dormant. 
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I dent i f i cat i on 

Periodic Dormancy 
SLEEP 

Purpose 

To a 1 low the user to place his program in dormant status and 
have it be automatically restarted after a predetermined 
amount of time has elapsed. 

.U-S-dfie 

As supervisor or library entry: 

CAL =n 

TSX SLEEP ,4 optional (TIA =HSLEEP) 

n is the actual number of seconds the user 
wishes to wait before restarting his program 
at l / 4. 

While the program is in dormant status/ the 
user may turn-off the alarm clock by issuing a 
new command or using the QUIT sequence. 
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I denti fi cation 

* Interrupt levels 

GETBRK, SETBRK, SAVBRK 

Purpose 

In order to allow a program to be interrupted from the 
console but continue running in some other section, programs 
may be organized to run on different interrupt levels. 

Res tr i ctions 

Command level is 0. Levels may be dropped to the maximum 

depth of 3. 

Me th od 

Command level and a program initially placed in working 

status are at interrupt level 0. A program may drop the 
interrupt level and set the entry point for each level. 

During execution, the level may be raised either by a 

program call to the supervisor or by the user sending the 
interrupt signal. The interrupt signal causes the interrupt 
level to be raised by 1 and control to be transferred to the 
*■ entry point previously specified by the program. 

An interrupt at level 0 will be ignored, (i.e., an interrupt 
cannot be used to QUIT). Each interrupt will cause the 
supervisor to print INT.n. where n is the level to which 
control is to be transferred. 

U sa A d 

SETBRK: 

as supervisor or library entry: 

TSX SETBRK, 4 optional (TIA =HSETBRK) 
P2E ' loc' 

SETBRK sets the interrupt entry point for the current 
level to the value of loc and drops the 
interrupt level by 1. 

SAVBRK: 

as supervisor or library entry: 

TSX SAVBRK, 4 optional (TIA =HSAVBRK) 

SAVBRK raises the interrupt level by 1 and returns in 
i the AC the entry point corresponding to the 

level just entered. If SAVBRK is called 
within level 0, the AC will be zero. 
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GETBRK: 

as supervisor or library entry: 

TSX GETBRK, 4 optional ( T I A =HGETBRK) 

Upon return, _ the AC will contain the value of 
the instruction location counter at the time 
the user last "interrupted". 


f 
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I dent i f i cat i on 


Storage Kiap 
STUMAP 

Purpose 

To print a storage map giving the entry names and locations 
of all subprograms in core B. 

Usage 

As library subroutine: 

TSX SWAP, 4 

The subprogram origin and the entry names and 
locations will be printed for all subprograms 
in core-B. 






CTSS PROGRAMMER'S GUIDE 


Section AG. 6. 05 


PAGE 1 


I den t i f i ca 1 1 o n 

FI oat i ng Point T rap 
.SETUP, (FPT), (EFTM), ( LFTM) 

Purpose 

To provide a means of initializing for, interpreting, 
recovering from, or flushing the program because of 
floating-point overflow or underflow. 

Method 

When the 7094 is operating in floating-point trap mode, a 
floating point operation which causes overflow or underflow 
will also cause a machine trap. The subroutine (FPT) will 
interpret the trap and take appropriate action. Some 
initialization must be done before the trap occurs to enable 
(FPT) to interpret the traps. .SETUP and (EFTM) are used in 
the initial i zat ion. 

Usage 

Mad and Fortran both automatically compile a calling 
sequence to .SETUP at the beginning of each main program. It 
need be executed only once per program. 

TSX .SETUP, 4 

The multiple tag mode (3 index mode) is 
entered. Location 8 is set to TTR (FPT). The 
floating-point trap mode is established by a 
call to ( EFTM) . 

A floating-point underflow will cause the 
execution of the TTR (FPT) which will then 
zero the offending register and return control 
to the instruction following the offending 
floating point instruction. 

A floating-point overflow will cause the 
execution of the TTR (FPT) which will then 
print a message on-line giving absolute and 
relative locations of the offending 
floating-point instruction with the name of 
the subprogram and the machine spill code. 
(FPT) then calls ERROR which prints a back 
trace of the subprograms previously called, if 
possible, and then calls EXIT. 
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( EFTM) and (LFTM) : 

as supervisor or library entries: 

TSX (EFTM), 4 optionaKTIA =H(EFTM) ) 

TSX (LFTM),4 optionaKTIA =H ( LFTM) ) 

(EFTM) enters floating-point trapping mode with 
trapping mode simulated in core B 

(LFTM) leaves the floating-point trapping mode. 

N.B. The LOAD command enters the multiple tag mode 
before completion. Consequently, a program 

loaded with the relocatable loader will be 
automatically initiated in 3 tag mode. 

f 

P 


4< i 

fW , 
■ 

•H * 

W 
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I den t i f i cat i o n 
Memory al 1 otment 

GETMEM, SETMEM, GMEM, SMEM, EXMEM 
Purpose 

To provide a way of determining or expanding the current 
memory allotment. 

Metho d 

At load time the memory allotment is set by the number of 
words required by the program. Memory protect ion, however, 
can only be set in blocks of 256 words and is therefore set 
to the next highest block of 256. If, during execution, the 
user wishes to change his memory allotment and/or 
protection, SETMEM may be called. 

Restrict ions 

Since memory protection is set in blocks of 256 words, it is 
possible that a program may store information beyond the 
memory allotment bound without causing a protection 
violation. However, swapping is done by memory allotment 
rather than memory protection, so that information thus 
stored is lost during swapping. 

As supervisor or library entries: 


TSX 

GETMEM, 4 

opt i onal 

( T 1 A 

=HGETMEM) 

CLA 

= 1 n 1 




TSX 

SETMEM, 4 

opt i onal 

( T 1 A 

=HSETMEM) 

GETMEM returns 

in the address portion 

of 

the AC the 

current 

memory allotment. 




SETMEM sets the memory allotment to the value of n. 

If n is (77777)8, all of memory is allotted, 
including location (77777)8. 

As library subroutines: 

MAD or FORTRAN: 

A = GMEM. (I ) 

A = SMEM.(J) 


FAP: TSX GMEM, 4 

P2E I 
STO A 


TSX SMEM, 4 
P2E J 
STO A 



PAGE 2 


CTSS PROGRAMMER'S GUIDE 


Sect ion AG . 6 . 06 


A and I Upon return, will contain an integer giving 
the current memory bound. 

J contains an integer giving the memory bound 
des i red. 

GMEM returns to the caller the current value of the 
memory bound. 

SMEM sets the memory bound to the value desired. 

To extend memory bound: 

As library subroutine: 

MAD, FORTRAN or FAP : 

A = EXMEM. (INC) 

INC contains an integer which will be used as an 
increment to extend the memory bound. 

A Upon return, A wi 1 1 contain the new memory 
bound which is the sum of the old memory bound 
and the increment in INC. If the sum is 
greater than (77777)8 or if the prefix of the 
argument is not P2E, TSX or TXH, return is 
made with A and the AC set to zero and the 
memory bound is not extended. 
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Identificatio n 

Free or erasable storage management 
FREE, FRER/ FRET 


Purpose 


One technique of optimizing the amount of core space 
required by one program is to have each subprogram within 
the program take temporary storage from a common pool and 
put it back when it is no longer needed. 

Usage 


As a library subroutine: 


AED: X=FREE ( N) $ , X»FRER(N)$, 


X=FRET ( N, X ) $ , 


FAP: TSX FREE/4 

P2E N 
STA X 


TSX FRER/ 4 
P2E N 
STA X 


TSX FRET/4 
P2E N 
STA X 


N contains an integer specifying the size of the 
block of storage. 


X contains (address) the address of the start or 
lowest location of the block of storage. If x 
is returned as zero by FRER/ no block could be 
obta i ned. 


FREE will find a block of storage either from free 
storage or by extending memory bound. If more 
space is requested than can be found/ the 
following message will be printed/ and EXIT is 
called: 

' nnnnn LOCATIONS OF FREE STORAGE ARE 

UNAVAILABLE 

(nnnnn is an octal number.) 


FRER serves the same function as FREE except that 
if not enough space is available/ return will 
be to the calling program with zero in the AC. 


FRET 


returns storage to free storage. If a block of 
storage being returned overlaps memory bound 
or any block previously returned/ the 
following message is printed and EXIT is 
called: 

** ILLEGAL CALL OF FRET, BLOCK rrrrr SIZE 
nnnnn 1 

(rrrrr is a pointer to the block, 
size; both in octal) 


i s 


nnnnn 
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Identf ication 

Reset file-wait return 
TILOCK 

Purpose 

A field called I LOCK exists within the UFD for each file. 
This field contains the number of users who currently have 
the file open for reading. Any user who tries to write in a 
file when I LOCK is greater than zero, will automatically be 
placed in file-wait status until no more users are reading 
the file. Any user who tries to open a file, which is open 
for writing or is waiting for a file-wait user to be able to 
open the file, will also be placed in file-wait status. A 
routine has been provided which allows the user to avoid 
f i le-wai t. 

Usage 

OLDRTN = T I LOCK. ( RETRN) 

RETRN is the location to which control will be 
transferred if an I/O call would normally 
result in file-wait. If RETRN is zero, the 
normal execution of file-wait will be 
rei nstated. 

OLDRTN upon return, the AC will contain the address 
of the previous return setting, if any. 
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I dent i f i ca t i on 

Query or modify supervisor parameters 
GETLOC, GLOC, SETLOC, SL0C / SYPAR 

Purpose 

To enable a user to examine a supervisor parameter. To allow 
the system programmers to modify an A-core parameter. 

Restr i ct ? ons 

SLOC and SETLOC may be used only by M1416 programmers. GLOC, 
SLOC and SYPAR may not be called from FORTRAN programs 
unless the location is shifted to the address rather than 
the decrement of LOC (or CODE). 


Usage 


Get the contents of a 
As supervisor or 


1 oca t i on : 

1 i brary entry: 


FAP: TSX GETLOC, 4 optional (TIA =HGETL0C) 

P2E LOC 
SLW WORD 


As library subroutine: 


MAD: WORD = GLOC. (LOC) 


Upon return, WORD will contain the contents of 
the A-core location whose address is in LOC. 

Set the contents of a location: 

As supervisor or library entry: 

FAP: CAL WORD 

TSX SETLOC, 4 optional (TIA =HSETL0C) 

P2E LOC 

As library subroutine: 

MAD: EXECUTE SLOC. (WORD, LOC) 

Upon return, the A-core location whose address 
is in LOC will be set equal to the contents of 
WORD. 
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Get a supervisor parameter: 
As library subroutine: 


FAP : 

TSX 

SY PAR, 4 


P2E 

CODE 


ST0 

PARAM 

MAD: 

PARAM 

= SYPAR. (CODE) 


SYPAR returns a supervisor parameter in the AC. 

CODE contains a right adjusted integer which 
specifies which parameter is desired. 

0 nothing 

1 Last or lowest COMMON location used 

2 COMMON length 

3 First location loaded 

4 Program length (i.e., memory allocation) 

5 System name 

6-9 reserved 

10+ Contents of A-core 


location 
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I dent i f i cat i on 

Get common file number 
GETCF/ GETCFN 

Purpose 

GETCF will find out the current common file directory number 
from the supervisor and return this information to the user. 

Method 

A supervisor entry has been provided which returns the 
common file directory number in the AC i n a packed way. A 
library subroutine has been provided which will unpack and 
convert this information so that it can be used by MAD or 
Fortran programs. 

Usage 

As a supervisor entry: 

TSX GETCF,4 (TIA =HGETCF ) 

Upon return/ the AC will be zero if the user is 
switched to his own file directory. Otherwise/ 
the AC will contain the number of the common 
file directory to which he is switched. 


As a 1 

i brary 

subrout i ne : 

FAP: 

TSX 

GETCFN, 4 


P2E 

CFN 


STO 

CFS 

FORTRAN: 

CFS = 

GETCFN(CFN) 

MAD: 

CFS = 

GETCFN. (CFN) 


Both CFN and CFS will be set to the current common 
file directory number (0/1/2..). In Fortran, 
the file directory number is returned as an 
integer. This same value may be used later to 
call COMFL(CFN). 
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I den t i f i cat i o n 

Privileged users' calls to the I/O system 

UPDMFD, DELMFD, ALLOT, ATTACH, MOVFIL, SETFIL, LINK 

Purpose 

Administrators and certain commands and utility programs are 
privileged to alter the supervisor and the accounting files. 
Certain calls to the I/O system may be invoked only by the 
privileged users or other users using the privileged 
commands. 


Method 

The accounting files contain the personal restriction codes 
for every user of the system. When a user logs in, his 
restriction codes are placed in a vector within the 
supervisor along with the other active users. When a user 
invokes a command, his personal restriction code is 'OR'ed 
together with the code of the command to make up the 
restriction code which becomes part of his machine 
conditions. The LOGIN command sets the low-order 6 octal 
digits of the user restriction code. 


1 

2 

4 

10 

20 

1000000 

2000000 

4000000 

10000000 

20000000 


User may use common files 

User may use privileged calls to the I/O 
system . 

User may modify "PROTECTED" files of other 
users . 

User may refer to "PRIVATE" files of other 
users . 

User may modify the supervisor and I/O 
system. 

User is background system 
User is foreground 
Use r is FIB 

User is incremental dumper 
User is privileged command. 


A privileged command sets the low order digits "on". The 
bits which occupy the decrement may be moved left six 
bit-positions to indicate the .not. condition. 


Usage 

Update MFD: 


U PDMFD . ( $ PR0BN$ , $ PR0G$) 



PAGE 2 


CTSS PROGRAMMER'S GUIDE 


Sect I on AG. 7. 03 


UPDMFD places a new user (problem number programmer 
number) in the master file directory. With 
this call it is possible to update the MFD 
during time sharing rather than having to wait 
for a disk editor run. 

PROBN is the right adjusted problem number of the 
form ANNNN . . A is an alpha character, and NNNN 
is a four digit number. 

PROG is a four digit programmer number. Note the 
right adjustment and blank padding. 

Error codes: 

03. User already in M.F.D. 

04. Machine or System error 


Delete from MFD: 


DELMFD . ( $ PR0BN$ , $ PR0G$) 

DELMFD will remove a user from the master file 
directory. The DELMFD will not be permitted 
if the user's record count is not zero. 

Error codes: 

03. User not found in M.F.D. 

Attach to UFD: 

ATTACH. ($ PR0BN$ , $ PR0G$) 

ATTACH will attach the user's program to the file 
directory of user PROBN PROG. The user now 
has ful1 access to the files and file 

di recto ry of PROBN PROG within the limits of 
his restriction code. Files which may have 
been, opened while attached to PROBN PROG 
remain. open even if the attachment is changed 
to a different file directory. 

Error codes: 

03. User not found in M.F.D. 

04. Machine or system error 

Quota al lotment: 


ALLOT. (DEVICE, QUOTA, US ED) 
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ALLOT may be used to allot a quota of records for 
each user, for each device by first ATTACHing 
to the users' file directory and then calling 
ALLOT. 

DEVICE is an integer or integer variable specifying 
the I/O device. 

1. Low-speed drum 

2. Disk 

3. Tape 

QUOTA is an integer or integer variable specifying 
the number of records to be allotted to the 
user on the specified device. A record is 
currently 432 words. 

USED is normally not specified and should be used 
only to correct an error in the number of 
records used. 

Error codes: 

03. Illegal device specified 

Move a file: 

MOVF I L . ( $ NAME1$ ,$ NAME2$,$ PR0BN$,$ PR0G$) 

MOVFIL is used to move the file NAME1 NAME 2 from the 
current file directory to the file directory 
of PROBN PROG. Upon return from this call, 
the file no longer exists in the current file 
d i rectory. 

E r ro r codes : 

03. File not found in current U.F.D. 

04. Fi le is a 'LINKED' file 

05. File is 'PROTECTED' 

06. File already exists in 'PROGN PROG' 

07. Machine or System error 

Link to a f ile: 

LINK. ($NAME1$ ,$ NAME 2 $ ,$PR0BN$,$PR0G$ ,-$NAM3$- ,-$NAM4 $-, -MODE- ) 

LINK establishes a link in the current file 
directory to a file in some other file 
directory. Links may be established to any 
depth . 

NAME1 NAME 2 is the name which will be used to refer 
to the file in the current file di rectory. 
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PROBN PROG specifies the file directory to which the 
link is being made. This file directory may 
contain the actual file or it may contain a 
link to some other di rectory. 

NAM3 NAM4 is the name by which the file is known in 
file directory PROBN PROG. If NAM3 NAM4 is 

NAi$El P NAME2? d ' C ° be the Same as 


MODE 


i s 
be 


an integer or integer variable which will 
OR ed with all the modes through all the 

J the . actual fi] e. The resulting 
OR ed mode will be used as the mode in the 
current file directory. If any one of the 
modes (except MODE) in the chain of links does 
not have the linkable mode bit, the file is 
not linkable and the error return will be 
taken. MODE need not be specified. 


Error codes 


03. Machine or system error 

04. 'PROBN PROG' not found in M.F.D. 

Date a file: 


S ETF I L . ( $ NAME1$ ,$ N AME2$, DA YTIM, DATE LU, MODE, DEVICE) 


SETFI L 


DAYTIM 


is used primarily by the file load and 
retrieval programs to create an entry in a 
file directory with a specific date and time 


is the date and time to be used as the 
and time last modified in the format of 
third word of a U.F.D.. (AD. 2) 


date 

the 


DATE LU 


is to be used as the fourth word of a U.F.D 
and contains the date last used and 'AUTHOR'.* 
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Identification 


General discussion of MACRO command programs 


Purpose 

It is sometimes desirable or 
initiate one command which 
execution of several commands, 
several programming levels for 
chains of commands. 


convenient to be able to 
results in the automatic 
Tools have been provided on 
initiating and controlling 


Discussion 

There are at least three levels of user interest in chain or 
macro command programs: 1) writing commands which may be 
used within chains, 2) initiating chains from within a high 
level programming language, 3) initiating chains at the 
machine language and supervisory call level of programming. 


Commands may be thought of as being subroutines without the 
conventional subroutine linkage. A standard command linkage, 
however, has been provided within the supervisor so that 
command arguments will always be available and retrievable 
from a standard place. All commands should terminate with a 
call to CHNCOM rather than one of the conventional 
programming terminal routines. CHNCOM will continue a 
command chain, if there is one, or call DORMNT (or DEAD, 
depending on the memory bound) if there is no chain. 
Routines that will fetch the command arguments are COMARG, 
which is callable by MAD or FORTRAN programs, and GETCOM, 
which is the supervisor entry. 


Two routines are available for executing single commands 
from the program level: NEXCOM is a limited-use supervisor 
entry and XECUM is a more flexible subroutine which may be 
called by MAD or FORTRAN programs. 

Chains of commands may be constructed in a simple way as BCD 
line-marked or line-numbered disk files and executed by the 
MAD or FORTRAN callable subroutine SCHAIN or by the command 
RUNCOM. SCHAIN and RUNCOM do a lot of the housekeeping and 
set up calls to the appropriate supervisor entries. 

On the more detailed level, chains may be constructed within 
the supervisor, the command location counter may be set or 
interrogated, and the chains may be executed and chained by 
calls to supervisor entries. On this programming level many 
of the housekeeping details must be handled by the user. 
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| dent i f i cat i on 

Single command 
XECOM, NEXCOM, NCOM 

Purpose 

To allow the user to execute a single command from the 
program level rather than the command level. 

Usage 

NEXCOM: 

as supervisor entry: 

CAL COMAND 

LDQ ARG1 

TSX NEXCOM, 4 (TIA =HNEXC0M) 

as library subroutine: 

NCOM. (COMAND/ ARG1) 

COMAND contains the BCD name, right justified/ of the 
command to be executed. 

ARG1 is stored as the first argument in the current 
command buffer. If there is to be no argument 
to COMAND/ ARG1 should be the fence. If COMAND 
expects an argument list and ARG1 is not a 
fence, the previous contents of the current 

command buffer will be used with ARG1 as the 

first a rgument . 

NEXCOM places the contents of the AC and MQ in the 

current command buffer and places the user in 

waiting-command status. Note that a fence is 
not placed in the command buffer following the 
argument. Control is not returned to the 

calling program except as may have been 
pre-arranged by CHNCOM. 

XECOM: 

as library subroutine: 

MAD, FORTRAN, FAP : 

K = XECOM. ( COMAND /LIST) 

EXECUTE XECOM. ( COMAND, LIST) 

COMAND contains the BCD name of the desired command. 
Right justification is not necessary. 

LIST is any legal list specifying locations which 
contain the BCD names of the arguments 
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appropriate to the command. Right 

justification is not necessary but the number 
of items in the list must be . LE. 18. 

K will be zero if execution was successful; non 
zero i f fa i 1 ure. 

XECOM builds a chain of SAVE, COMAND, RESUME and 
calls CHNCOM. Thus control will be returned to 
the calling program after execution of COMAND, 
if COMAND called CHNCOM. 
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| den ti f i ca ti on 

MACRO command 
S CHAIN 


Purpose 

To allow the user to build a macro command program as a BCD 
disk file and call for its execution from the program level 
rather than command level. A macro command program is a 
chain of commands which can be executed by issuing just one 
command/ with or without arguments. 


Reference 

SCHAIN is the subroutine call which is the equivalent of the 
RUNCOM command. For a complete explanation/ see section 


AH. 10. 01 / RUNCOM. 

U$a£S 

MAD, FORTRAN or FAP: 

A = SCHAIN 
EXECUTE SCHAIN 


(FI LNAM/-ARG1/ ARG2. . . .ARGN-) 
(FI LNAM/-ARG1, ARG2. . . . ARGN-) 


w 


* 


FILNAM specifies the BCD file containing the 

chain of commands to be executed. The 
secondary name need not be BCD as is required 
for RUNCOM. 

ARG'S are locations of BCD names of specific 

arguments to be substituted for the dummy 
arguments specified by the CHAIN 

pseudo-command. They may be single or list 
variables and the names need not be right 
justified. 

A Upon return may contain a word of the 

form. ..XXX/ which is not an error, but the 
primary name of a SAVED file representing the 
last dormant status yielded by the last 
command in the chain. 

SCHAIN will intersperse SAVE's and RESTOR's or 
RESUME's so that the chain specified in FILNAM 
may be of any length. Control is returned to 
the calling program upon completion of the 
chain. The chain may include any number of 
RUNCOM specifications, since nesting and 
recursion are possible. 












. 
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I denti f i cation 
Chain control 

CHNCOM; ( GET, G, SET, S) CLS; ( GET / G / SET / S) CLC 
Purpose 

To allow a user to set up and control chains of commands 
from the program level rather than command level. These 
routines are close to the supervisory level and require 
detailed control by the user. 


idfi.t ho<j 


In order to build a chain of commands, the BCD name of each 
command and its arguments must first exist in a fenced 
vector. The vector for each desired command is then moved 
into a command buffer within the supervisor and entered into 
its relative location within the command list (CLS) by the 
supervisor routine SETCLS. The relative location of the 
first command to be executed in the command list is entered 
into the command location counter (CLC) and the length of 
the command chain is entered into the supervisor by SETCLC. 


Execution of the chain is initiated and continued by calls 
to CHNCUM. Commands can only be chained if each command 
terminates by calling CHNCOM so that the next command in the 
chain can be initiated. The calling sequence to CHNCOM 
specifies whether or not the calling program has a 
significant core image which might be useful to the next 
command in the chain. CHNCOM does some housekeeping before 
calling the next command in the chain: 1) sets memory bound 
to zero if no core image was specified in the calling 
sequence, 2) sets the instruction location counter to be the 
word following the calling sequence to CHNCOM, 3) increments 
CLC by 1, and 4) moves the next command buffer into the 
current command buffer or calls DEAD or DORMNT if no command 
remains in the chain. 

Restr i ctions 

A command list must be . LE. 5 commands. 

Each command buffer with fence must be .LE. 20 words. 



COMMAND 
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Usage 


To enter a command in 
As supervisor or 


the command list or command buffer: 
1 i brary entry: 


TSX S ETCLS, 4 optional (TIA =HSETCLS) 

PZE TAB/ / 1 n ' 


• • • 

TAB BCI 1/ command 
BCI 1/ argl 

OCT 777777777777 


As library subroutine: 

MAD or FORTRAN: 

EXECUTE SCLS . (TAB/N) 

SETCLS moves 20 words from TAB into the Nth. command 
buffer in the command list/ or into the 
current command buffer if N is 0. A call to 
SETCLS with N = 0/ does not initiate a 
command. A cal 1 to NEXCOM or XECOM is 

required to initiate the command. 

SCLS interprets MAD and FORTRAN calling sequences 
which specify backward arrays and moves the 
words from TAB only to and including the fence 
into the command list. 

TAB is the location of the fenced command table 
(.LE. 20 words) containing the command and its 
arguments in BCDCright justified and blank 
padded). The fence is interpreted by the 
command and SCLS not by SETCLS. 

N & n specify the position within the command list 
(.LE. 5). N = 0 specifies the current command 
buffer. 

To retrieve a command from the command list or current command buffer 
As supervisor or library entry: 

TSX GETCLS/4 optional (TIA =HGETCLS) 

PZE BUF F/ , ' n ' 

As library subroutine: 

MAD or FORTRAN: 

EXECUTE GCLS. (BUFF/N) 

GETCLS moves 20 words from the nth command buffer of 
the command list into locations beginning at 
BUFF. 
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GCLS interprets MAD or FORTRAN calling sequences 
calls GETCLS and stores the command buffer 
backwards in BUFF. Only the words to and 
including the fence are moved into BUFF. 

BUFF must be at least 20 words long for GETCLS. 

To set the command location counter: 

As a supervisor or library entry: 

CLA A 

TSX SETCLC / 4 optional (TIA =HSETCLC) 
As a library subroutine: 

MAD or FORTRAN: 

EXECUTE SCLC . (M,N) 

A t?rrfl nS a , W ° r J the form P2E m " n - Both 
SETCLC and SCLC set the command location 

counter to m and the number of the last 
command in the chain to n. 

M or m is the number of the command in the command 

list which is the next to be executed, (m .LE. 

N or n is the number of the last command in the 

command list, (n . LE. 5) . 

To query the command location counter: 

As supervisor or library entry: 

GETCLC, 4 optional (TIA =HGET C LC ) 


As library subroutine: 

MAD or FORTRAN 

A = GC LC (M,N) 

M will be set to the value of the command 

location counter i.e., the position within the 
command list of the next command to be 
executed. (m . LE. 5 ) . 

N will be set to the position of the last 

command in the command list.Cn .LE. 5). 

A wi 1 1 be set to a word of the form PZE 


m / / n • 
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To initiate or continue a chain: 

As supervisor entry: 

TSX CHNCOM, 4 (TIA =HCHNC0M) 

P2E ' j ' 

As library subroutine: 

MAD or FORTRAN: 

EXECUTE CHNCOM (J) 

FAP: CAL = 'j' or TSX CHNCOM, 4 

TSX CHNCOM, 4 P2E ' j ' 

J or j j =0 specifies to CHNCOM that no core image is 
available for the next command. j=l means that 
a core image is available and may be used by 
the next command. 

CHNCOM determines whether or not another command 
exists in the chain. If one exists, it is 
initiated. If no chain exists; DORMNT is 
called if j=l, DEAD is called if j =0. 
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i dpnti f i cati on_ 

Fetch a current command argument 
GETCOM, COMARG 


Purpose 

To extract the Nth argument from the current command buffer 


Usase 

As supervisor or library entry. 

TSX GETCOM/ 4 
P2E 'n' 


optional C T I A -HGETCOM) 


GETCOM 


returns, in the logical AC, the Nth argument 
of the user's latest command/ i.e./ or ine 
current command buffer. The command itself is 
number 0. The arguments may be numbered 1 19/ 
including the fence. 


> 


As 


1 i brary subrouti ne: 

MAD/ FORTRAN or FAP: 


A = COMARG. (N) 

A = COMARG. (N/B) 

EXECUTE COMARG. C N/B) 

The Nth argument of the current command buffer 
is transferred to A and/or B. 


► 





♦) 
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Identification 

Trace of Subroutine Calls. 

ERROR 

Purpose 

MAD, or 
the main 
chain of 


PnR?»AM S a sub P ro ? ram which may be called by FAP, 
F0RT RAN programs in order to trace backwards to 

submuMnp th 1 r ? ugh the most recently executed 
suproutine calls. 


Restr i ct i nns 

If FAP subprograms are used, 
director and the instruction 
register 4 must be included 
of the subprogram. 


they should include the linkage 
to savethe contents of index 
n the first twenty instructions 


Each subprogram executed must have at least one argument. 


I f ERROR. i s unable to 
message is printed and 
prog ram. 


complete the trace, the following 
control is returned to the calling 


TRACE FA I LURE IN 'sub' 
EXIT FROM ERROR 


MAD, FORTRAN, or FAP: 


ERROR. (MESS) 


MESS 


is. a BCD fenced message of .LE. 
which will be printed on the 
when ERROR is entered. 


132 characters 
user's console 


ERROR 


will trace back to the main program 
the last subroutine calls and print 
of the following type and then return 
to the calling program. 


through 
comments 
cont ro 1 


C (MESS ) 

ENTRY ERROR 
ENTRY ' subl ' 


CALLED BY 
CALLED BY 


ENTRY ' subn ' CALLED BY 
EXIT FROM ERROR 


'subl' 
' sub2 ' 


(MAIN) 







V 

I 


I 


li' 

. 1 - 




9J 


i 
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I den t i f i cat i on 

BCD or spread-octal to binary 

BCDEC/ BCOCT 

Purpose 

To convert the BCD or spread-octal representation of an 

integer to the equivalent binary integer. 

Usage 

BCD to binary: 

As library subroutine: 

FORTRAN: EQUIVALENCE (XNUM, NUM) 

XNUM = BCDEC (X) 

MAD: NUM = BCDEC. (X) 

FAP : TSX BCDEC, 4 

PEE X 
STO NUM 

X is the location of the BCD word to be 
converted. X is assumed to be a BCD decimal 
integer and leading blanks and signs are 
ignored . 

NUM and the AC will contain the r i ght- j us t i f i ed 
binary integer equivalent to the absolute 
value of X. 

Spread-octal to binary: 

As library subroutine: 

FORTRAN: EQU I VALENCE ( XNUM, NUM) 

XNUM = BCOCT ( X ) 

MAD: NUM = BCOCT. (X) 

FAP: TSX BCOCT, 4 

PZE X 
STO NUM 

X is the location of the spread-octal word to be 
converted. X is assumed to be a BCD octal 
integer and leading blanks and sign are 
i gnor ed . 

NUM and the AC will contain the r i gh t- j us t i f i ed 
binary integer equivalent to the absolute 
value of X . 
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Identifi cation 

Binary to BCD 
DEFBC/ DELBC, DERBC 

Purpose 

To convert a binary integer to BCD with leading zeros. 
Usage 

As library subroutine: 


MAD 

or FORTRAN: 



A = DEFBC. (K) 

A = DELBC. (K) 

A = DERBC. (K) 


A 

will contain a BCD decimal number (modulo 
999999), right-justified and zero padded. 

DEFBC 

converts the full 35 bit word 
ignored) K into a BCD decimal number. 

(sign is 

DELBC 

converts the left half of K (sign is 
into a decimal BCD number. 

i gnored ) 

DERBC 

converts the right half of K into a 
BCD number. 

dec i ma 1 
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Identi f ication 

Binary to spread-octal 
OC ABC/ OCDBC/ OCLBC/ OCRBC 

Pu rpose 

To convert binary fields to spread-octal which is suitable 
for printing. 

Usage 

As library subroutine: 

MAD or FORTRAN: 

A = OCABC.(X) 

A = OCDBC. (X) 

A = OCLBC. (X) 

A = OCRBC. (X) 

X contains the binary number to be converted 


A will contain the converted value in spread 
octal/ i. e w six bits for each octal digit 
(0-7). 


OCABC 

converts the 
with lead i ng 

address field of X to 5 
blank. 

digits 

OCDBC 

converts the 
with leading 

decrement field of X to 5 
blank. 

digits 

OCLBC 

converts the 

left half of X to 6 digits. 


OCRBC 

converts the 

right half of X to 6 digits 

• 
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| Hpnt i f i cat i on 

Justification and padding 
BEEL,ZEL, LJUST, RJUST 

purpose 

To allow the user to left or right justify and/or to 
interchange blanks and zeros. 

Usage 

Justification library subroutines: 


FAP: 

TSX 

PEE 

ST0 

LJUST, 4 

WORD 

X 

TSX 

PEE 

ST0 

RJUST, 4 

WORD 

X 

MAD : 
FORTRAN: 

X = 

1 = 

LJUST. (WORD) 
LJUST (WORD) 

X = 

1 = 

RJUST. (WORD) 
RJUST (WORD) 


WORD contains the word to be justified. Upon return 
the AC contains the adjusted word. 

LJUST by left shifting/ leading blanks are replaced 
by trailing blanks. Leading zeros are not 
replaced. If the word is all blanks/ "bbbbb*" 
i s returned. 

RJUST by right shifting/ trailing blanks are 

replaced by leading blanks. If the word is 
all blanks, "bbbbb*" is returned. 

Interchange leading zero and blanks/ library subroutine: 

MAD, FORTRAN or FAP: 

A = BEE L (B) A = EEL CB) 

B contains the word to be modified. Upon 

return, the AC and A will contain the modified 
word . 

BEEL replaces leading zeros with blanks. If B is 

zero, "bbbbbO" will be returned. 

EEL replaces leading blanks with zeros. If B is 

all blanks, "00000b" will be returned. 








’ 
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I den t i f i cat i on 

General purpose input/output conversion 
( I OH ) / (RTN), (FI L ) , I OH S I Z / STQUO 

Purpose 

General purpose conversion of BCD to binary or binary to BCD 
for input or output, respectively, according to a format and 
data list. 

Refe rence 

CC 186 FORTRAN and MAD Format Specifications Spall 
Method 

A standard 22 word buffer is assumed to be located at 
(77742)8. Presetting of certain upper core locations 
indicates whether input or output conversion is desired. If 
input is indicated, the contents of the buffer is converted 
according to the specified format and stored in the 
locations specified by the list. If output is indicated, 
data from the list specification is converted according to 
the format and stored in the buffer. 

The actual I/O data transmission to or from the buffer must 
be performed by an I/O routine. Appropriate calling 
sequences to the I/O routines and (I0H) are compiled by MAD 
and FORTRAN for any read/write statements which specify a 
format. Data or format errors cause (I OH) to call RECOUP. 

Uspge 

Output, binary to BCD: 

Fortran: MAD: 



TSX 

USRSTH, 4 


TSX 

USRSTH, 4 


PZE 

FORMAT,, SWI TCH 


PZE 

FORMAT, ,SWT 

RTN 

• 


RTN 

• 



LDQ 

SYMBOL, t 


STR 

F 1 RST, , LAST 


STR 

• 



• 

• 



TSX 

• 

(FI L) , 4 


STR 

• 

0 

USRSTH 

Set 

upper 

USRSTH 

Set 

upper 


core Iocs 


core Iocs 


TRA* 

( 1 OH) 


TRA* 

( I0H) 

OUT 

• 


OUT 

• 



TRA 2,4 


TRA 2,4 
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Input, BCD to binary: 


Fo rt ran 

RTN 

TSX 

PEE 

• 

USRTSH, 4 

FORMAT, /SWITCH 

MAD: 

RTN 

TSX 

PEE 

• 

• 

USRTSH, 4 
FORMAT,, SWT 


STR 

STQ 

• 

SYMBOL, t 


• 

STR 

• 

F 1 RST, , LAST 


• 

TSX 

• 

(RTN), 4 


• 

STR 

• 

0 

USRTSH 

1 N 

• 

Set 

TRA* 

• 

upper core 
( I0H) 

• 

USRTSH Set 
TRA* 
IN 

upper core 
( I0H) 


TRA 1/4 


TRA 1,4 


FORMAT is the beginning location of the desired 
format . 


SWITCH is zero if the format is enclosed in 
parentheses and stored backwards in core. 
SWITCH is non zero if the format is enclosed 
in parentheses and stored forward in core 
(e.g. BCD. 

SWT is zero if format is forward. SWT is one, if 
the format is stored backward. 

SYMBOL/t locates the variable to be converted. A loop 
may be included here for arrays or a series of 
LDQ, STR. After each variable is converted by 
(I0H), return is made following the STR in 
order to find the next variable to be 
converted . 


FIRST is the starting location of the list. 

LAST is the final location of the list. LAST may be 
lower in core than FIRST. If the list is of 
length one, LAST is zero. 
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(FIL) is called to indicate that all the output data 
has been converted and the current buffer 
' should be truncated. 

STR 0 terminates the list in a MAD call. 

(RTN) is called upon completion of the input data 
list. It restores the original (I0H) 
initialization (i.e., trap cells). 

USRSTH is the user's output transmission program. It 
must initialize the appropriate upper core 
locations before calling (I0H). After each 
line image is completed in the buffer/ (I0H) 
will return to OUT with index register 4 set 
in such a way that "CLA 1/4" will put into the 
address of the AC the location of the buffer 
and in the decrement of the AC the number of 
words in the buffer. 

For MAD programs/ USRSTH will be .TAPWR and 
for FORTRAN programs it will be CSTH) or 
(STHM). 

USRTSH is the user's input transmission program. It 
must initialize the appropriate upper core 
locations/ read in the first buffer load and 
then call (I0H). Control is then returned to 
FIRST and the first data word is converted and 
placed in the MQ upon entry to (I0H) by way of 
the STR. Successive words are converted into 
the MQ by subsequent STR's. 

An STR following depletion of the input buffer 
causes (I0H) to return control to IN in order 
to read the next record. 

For MAD programs, USRTSH will be .TAPRD and 
for FORTRAN it will be ( TSH ) or (TSHM) . 


I0HSIZ: 

MAD, FAP, or FORTRAN 

TSX IOHSIZ/4 
P2E N 

N containing non-zero indicates to (I0H) that 
the diagnostic that "the field width of the 
format lias been exceeded" should be 
suppressed. An N of zero resets the normal 
mode of printing the diagnostic. 
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STQUO : 

MAD, FAP, or FORTRAN 
TSX STQUO, 4 

The next I/O statement will be initiated 
without resetting the buffer, that is, the 
line pointer is left where it was at the 
conclusion of the last I/O call. This is 
normally used in conjunction with the N 
modifier. (CC-186 for description of formats). 

The following locations must be set before (I0H) is called 
for conversion: 

(77737)8 address Location of subroutine that (I0H) calls 

for input or output. This address 
corresponds to INPUT or OUTPUT. 

Tag 0 

decrement +1 if format stored backwards -1 if 
format stored forwards 

prefix TXL if FORTRAN type call TXH if MAD type 
ca 1 1 

(77740)8 address location of first word of format 

statement . 
tag 0 

decrement user's index register 4 on initial entry 
to the input-output subroutine. 

prefix TXL for on-line printer TXH for all 
other I/O 

(77741)8 address scratch area for (I0H) to use for 

output. The number of words in the 
output record is stored here, 
tag 0 

decrement maximum number of columns available in 
input or output record (may not exceed 
132). 

prefix TXL for output (binary to BCD). TXH for 
input (BCD to binary). 

(77742)8 The beginning of a 22 word buffer from 

which BCD data is converted to binary or 
into which BCD data is placed after 
binary to BCD conversion. 

(77771)8 address location of symbol table (if any) 

0 address the address of RTN as RTN is the 
location to which programs should return 
after calling ( I OH) . 
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' entif ication 

Pack and unpack, single characters to full words 
PAKR, PAKL, UNPAKR, UNPAKL 

Purpose 

The characters from an array containing one 6-bit character 
per word may be packed into an array containing six 6-bit 
characters per word. Conversely the packed array may be 
unpacked . 


Usage. 

As a library subroutine: 


MAD: NUM- 

NUM= 
NUMB = 
NUMB- 


PAKR. (CR. . .CR( I ), WD. . .WD( J) ) 
PAKL. (CL. . . CL( I ), WD. . .WD( J) ) 
UNPAKR. (WD...WDCJ), CR...CR(I) ) 
UNPAKL. ( WD . . . WD ( J ) , CL...CLCI) ) 


TSX 

PAKR, 4 

TSX 

PAKL, 4 

T 1 X 

CR, ,CR-' i ' 

TIX 

CL,, CL-' 

TIX 

WD, , WD - 1 j ' 

TIX 

WD, , WD- ' 

STO 

NUM 

STO 

NUM 

TSX 

UNPAKR, 4 

TSX 

UNPAKL, 4 

TIX 

WD, , W D — * j ' 

TIX 

WD, , WD- ' 

TIX 

CR, , CR- ' i ' 

TIX 

CL,, CL-' 

STO 

NUMB 

STO 

NUMB 


CR is an array of words, each containing one 
right adjusted 6-bit character. 

CL is an array of words, each containing one left 
adjusted 6-bit character. 


WD is an array of words containing six 6 bit 
cha r ac te r s . I f the last word is not full it is 
left adjusted and blank padded. 

NUM and the AC will contain the number of words 
entered i nto WD. 

NUMB and the AC will contain the number of words 
C i . e . , characters) entered into CR or CL. 


PAKR or PAKL will take successive characters from 
(right adjusted) or CL (left adjusted), 

respectively, CR and pack them into successive 
words in WD . 

UNPAKR or UNPAKL will unpack the words in_WD as one 
character per word with blank padding into CR 
(right adjusted) or CL (left adjusted), 

respecti ve 1 y. 


1 


) 


0 
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Identification 

fortran integers to/from full word integers. 

F I NT/ MINT 

3 ur nose 

c ortran II integers occupy the decrement portion of a 
:omputer word. Most other systems, including MAD, use full 
word integers. These two routines will convert from 
decrement to full word or from full word to decrement. 

Usage 

4s a library subroutine: 

Fortran: EQUIVALENCE (A,J) 



A = 

FINT ( 1 ) 

1 = 

MINT (J) 

MAD: 

J = 

FINT. (1) 

1 = 

MINT. (J) 


INTEGER J, FINT., 1 

INTEGER 1, MINT 

FAP: 

TSX 

FINT, 4 

TSX 

Ml NT, 4 


P2E 

1 

F2E 

J 


STO 

J 

STO 

1 


I is a full word (MAD) integer. 

J is a decrement (FORTRAN) integer. 

A is equivalent to J. 

F I NT converts from full word to decrement integer. 

If the integer is too large, the following 
message will be printed and the integer will 
be taken modulo 32768. 

MAD INTEGER EXCEEDS 32767 

MINT converts from decrement integer to full word. 








' 
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I dent i f i cat i on 

Variable length calling sequence processor 
COLT/ SELAR/ MDL 

Purpose 

To provide one routine which general purpose subroutines 
might call to interpret va r i abl e- 1 ength calling sequences 
generated by MAD/ FORTRAN or FAP . This routine will 
determine the type of calling-program and the number and 
type of arguments in the calling-program. 


Usage 

Local definitions: 

Program is the routine which is calling COLT. 
Calling-program is the routine which is calling 
the program. 

COLT/ as a library subroutine: 

TSX COLT/4 
P2E IR4 

I R4 contains/ 1 in the decrement/ the contents of 

index register 4 at the time the program was 

called. 

AC upon return/ will contain, in the decrement, 
the number of arguments in the calling 
sequence to the program and, in the address, a 
code specifying the type of the 

calling-program. The codes are: 

0 unknown, or no arguments 

1 FAP 

2 FORTRAN 

3 MAD 

Index register 4 will contain the two's complement 
of the location in the calling-program to 
which the program should return, i.e., the 
location following the calling sequence. 
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SELAR; what type of argument: 

CAL* COLT 
STA SELAR 
CAL ARG 
AXT RETURN, 1 
SELAR TRA ** 


RETURN 

ARG Is the argument from the calling-program 
which is to be examined. 

RETURN is the location to which SELAR is to return. 

SELAR will place a code in index register 1 
indicating the type of argument 

0 unknown 

1 FAP 

2 FORTRAN 

3 MAD single argument 

4 MAD list with T I X 

5 MAD list with STR 

AC upon return, will contain in the left half the 
significant part of the argument (TXH, TSX 
etc. ) 

MDL, MAD list processor: 

CAL* COLT 
ARS 18 
STA MDL 
CAL ARG 
MDL TSX **,1 

ARG is the MAD list argument from the 
calling-program to be examined. 

AC upon return will contain: 

address - number of words in the list 
decrement - the increment to be used in 
i ndex i ng ( +1 or -1 ) 

prefix - TXH (plus) if the list is 
forward or TXL (minus) if the 
list is backward. 
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Mpntif ication 

Determine type of calling program and FILNAM 
GNAM 


Purpose 


To provide a routine which general purpose routines 
call to determine the type of calling-program and a 
name if one be requested. 


might 

file 


Usage 

Local definitions: 

Program is the routine 
Calling-program is the 
the program. 


which is cal 1 i ng GNAM. 
routine which is calling 


As library subroutine: 


TSX GNAM/ 4 
PEE IR4 
-OPN FILNAM- 

OPN may be PEE/ TXH/ or TSX. 

IR4 contains/ in the decrement/ the contents of 
index register 4 at the time the program was 

cal led. 


F I LNAM 


(optional) is the first of two consecu 
locations in which the file name will 
stored (forward if P2E, backward if TXH). 
file name is assumed to be located by 
first argument in the calling sequence to 
program. 


t i ve 
be 
The 
the 
the 


AC will contain a code, right-adjusted integer, 
specifying the type of the calling-program. 

0 unknown 

1 FAP 

2 FORTRAN 

3 MAD 
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I rAant i f i ca t i on 

List transmission 
M0VE1, MOVE2, M0VE3 


Purpose 

To tramsmit data specified by an argument list from the 
railing program to the called program or transmit any list 
specified data from one place to another. The argument 
lists may be MAD, FORTRAN or FAP and the data arrays may be 
forward or backward. 


Usage. 

As library subroutine: 


TSX M0VE1, 4 

OP BGDATA, , -ENDATA- 

OPN 

TSX M0VE2, 4 
OP BEGLST, , -ENDLST 

ALPHA OPN 

STR DATOUT,, LSTOUT 

BETA OPN 

TSX M0VE3, 4 

OP may be TSX, TXH, PZE, TIX or STR. The 
decrement argument may be used only with iia 
and STR. 

TSX and TXH signify a single argument or 
backward array base. 

PZE signifies a single argument or forward 

array base. . 

TIX and STR signify an argument list whose 
beginning location is specified in the address 
and whose ending location is specified in the 
decrement. Note that the list may be forward 
or backward depending on whether the address 
is less than or greater than the decrement. 

BGDATA is the beginning location of a block of core 
in the program in which the data will be 

stored. 

ENDATA (specified only when OP is TIX or STR) is the 
ending location of the data block. 

BEGLST is the begining location of the list which 
specifies the data to be moved. 

ENDLST (specified only when OP is TIX or STR ) is the 
ending location of the argument list. 
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ALPHA 

STR 


DATOUT 

LSTOUT 

OPN 

MOVE1 

MOVE2 

MOVE3 


is the return from MOVE2 at which time the AC 
BEGLST nS the f ' rst data ' tem as specified by 


causes the storing of 
specified by BGDATA . 
block, return is made 
meaningless. The next 
is then placed in the 
BETA. I f there i s 
return is made to 


no next 
LSTOUT. 


the AC in the data block 
I f th i s f i 1 1 s the data 
to DATOUT and the AC is 
data i tem from the 1 i st 
AC and return is made to 
item in the list. 


If BEGLST was specified as an array base, 
successive STR's will cause the transmission 
of successive elements of the array. The 
number of elements thus transmitted must be 
controlled by the user. 


is the return location if the data block is 
full. The AC is meaningless. M0VE1 may now be 
called again to initialize another data block. 

is the return location if the list is 
exhausted . MOVE2 may be called to specify 
another list or another STR may be executed if 
moving an array. 


may be any programming to establish loops 
use or modify the AC If desired. 


and 


initializes addresses and indexing for the 
data block and also initializes the STR trap 
cells to entries to this routine. 

initializes addresses and indexing for the 
list, initializes the trap cells if not 
already done, and gets the first data item in 


restores the trap cells. 


y 
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Identi fi cation 

Name a format or file name 
SETFMT, SETNAM 

Purpose 

To simplify FORTRAN calls to the library disk routines by 
providing formats and file names with labels which then may 
be used in calling sequences to library routines. 

Usage 

FORTRAN: CALL SETNAM (FILNAM,12H NAM E 1 NAME2) 

CALL SETFMT (FORMAT , nH ( ) ) 

F I LNAM is the location which is to contain a pointer 
to the actual file name NAME1 NAME2. 

NAM E 1 NAME 2 are the actual primary and 

secondary names of the file, r i ght- j us t i f i ed . 

FORMAT is the location which is to contain a pointer 
to the actual format. 

pointer is a word which contains in the address 
portion the address of the first word of 
either the format or file name. The left half 
will contain a TSX if the call was made by a 
Fortran or FAP program or a TXH if the call 
was made by a MAD program. Bit positions 
12-17 will contain (77)8. 

These two routines allow the library disk routines to 
be called with F I LNAM and FORMAT as arguments instead 
of the actual BCD information. 

i. e. , CALL DWRITE (FI LNAM, FORMAT, LIST) 
instead of, CALL DWRITE ( 12H NAM El NAME 2, nH(...*), LIST) 



■».V : 



0 
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f i cation 

Get the date and time of day 
GET I ME/ GETTM 

p^ir posg 

To provide the user with the current date and time of day. 

[viethod 

The time is computed by using values from the interval timer 
to update the last reading of the chronolog clock (last time 
someone logged in). The interval timer is incremented sixty 
times a second. 

Usage 

As supervisor or library entry: 

TSX GET I ME/ 4 optional (TIA =HGET I ME) 
SLW TIME 
STQ DATE 

Upon return, the logical AC will contaan the 
time of day as in integer in 60ths of a 
v second. The MU will con t a in the date in BCD as 

"MMDDYY". 

As library subroutine: 

MAD, FURTkAIM or FAP 



CALL 

GETTM (DATE, TIME) 



DATE 

i s the 

location in which the 

date 

wi 11 


s tored 

in the BCD form "MM/DDb" 

• 


TIME 

i s the 

location in which the 

t i me 

will 


stored 

in the BCD form "HHMM.M" 

. HH 

i s 


hour of the day (0-23) and MM.M is the minutes 
after the hour to one tenth of a minute 
(U-59.9) 
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I denti f ication 

Timer interrupt and stop watch • _ IMI __ dqtbtn 

TIMER/ JOBTM/ RSCLCK/ STOPCL/ KILLTR, TIMLFT/ RSTRTN 

Purpose 

To provide the user with the ability to time parts of a 
program and/or set a time limit on parts of a program. 

Method 

The foreground supervisor normally runs "ithfhe clock 
function turned off. A call to any of these time routines 
will turn the clock on. The interval timer is then used to 
time the function as specified by the user. The interval 
time is incremented sixty times a second so that all integer 
times will be in 60ths of a second. 

Restrictions 

The simulated clock (core B interval timer cell) may cause 
an interrupt only every 200 milliseconds because that s how 
often it is updated by the supervisor/ but it will oe 
incremented every 60th of a second. The execution of any 
command (e.g., MACRO or CHAIN) will turn the clock function 
off The job time is initiated to 73 minutes upon. the t irst 
call to the timer rather than at the actual beginning of the 
job. CLOCON and CLOCOF should not be used if the timer 
routines are being used. 


Usage 


A1 1 of the 
the prefix to 
FAP) the integer 
the prefix is zero. 


entries may be called by MAD, FAP or FORTRAN, 
the argument is non-zero (i.e./MAD or TXH 
variable will be full word integers. 

will be in the decrement 


I f 
i n 
If 


the integers 


To initialize or reset the stop watch to zero: 

EXECUTE RSCLCK. 

To read the elapsed execution time since the last call to 
RSCLCK: 

EXECUTE STOPCL. (J) 

J is an integer variable which will contain the 
time used since the last call to RSCLCK in 
60 ths of a second. 

To read the elapsed execution time since the first 
initialization of the clock: 
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EXECUTE JOBTivi. (j) 

U is an integer variable which will contain the 
elapsed execution time since the first call to 

one of the timer routines in 60ths of a 
second. 

tial l2e an elapsed time interrupt, i.e., an alarm 


FORTRAN: ASSIGN S TO N 

CALL TIMER (J,N) 

MAD: EXECUTE TIMER. (J,S) 

FAP: TSX T I MER, 4 

PEE J 

PEE S 

J is an integer variable specifying the length 
of time in 60ths of a second that the clock 
may run before interrupting. 

S is the statement (location) to which control 

o^n U ? 11 transfer when the time ' to the nearest 
200 mi 1 1 eseconds, has elapsed. 

TIMER Only nine calls to TIMER may be stacked. Any 
mo re than nine will be ignored. 

To continue the instructions which were interrupted by the 
alarm clock: y 


EXECUTE RSTRTN . 

To void the last setting of the alarm clock: 

EXECUTE KILLTR. 

To provide foreground/background compatibility to job time 
remaining: J L "" e 

EXECUTE TIMLFT. (J) 

J is an integer variable which will contain the 
amount of time in BOths of a second which the 
job has remaining to run. The first call to 
any of the timer routines will initialize the 
job run time to 72 hrs. The job run time for 
background jobs is taken from the 

identification card. 
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Identification 

CLOCK function 
CLOCON, CLOCOF 

Pur oose 

To cause the supervisor to simulate the interval timer for 
the user. 

Method 

If the clock function is on, the B core interval timer cell 
will be updated by the supervisor at each time burst (200 
m i 1 1 i seco nds) * It will be updated by the elapsed ti me 
(running time, not real time) in 60ths of a second. Any 
B-core interval timer overflow trap will be interpreted at 
the time of the update. 

Usage 

Turn the clock function on: 

As supervisor or library entry: 

TSX CLOCON, 4 optional (TIA =HCL0C0N) 

Turn the clock function off: 

As supervisor or library entry: 

TSX CLOCOF, 4 optional (TIA =HCL0C0F) 
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I denti f i cati on 

List of miscellaneous library subroutines: 

The following is a list of miscellaneous TSLIB1 
Further information or one page write-ups may 
from the consultants. 


DFAD 

DFSB 

DFMP 

DCEXIT 

DFDP 

I0SET 

10PAR 

I0END 

IOSCP 

I0ITR 

COM 

ORA 

ANA 



SL0 

SLI 




.01300 

. 01301 

.01311 

. 03310 


MAX0 

MAXI 

XMAXU 

XM AX 1 


Ml NO 

MINI 

XMIN0 

XMIN1 


MOD 

XMOD 




XSIGN 

SIGN 

XLOC 



DIM 

XDIM 

1 NT 

XI NT 

XFIX 

EXP 

EXP(1 

EXP( 2 

EXP( 3 


ACUS 

AS 1 N 

ATAN 

ATN 

COS 

LOG 

SORT 

SUR 

TAN 

COT 

S IMCS 

XSMEU 

XSIMEQ 

XDETRM 

XDTRM 

FLI P 

RANNO 

SETU 

1 NDV 

DPNV 


subrout i nes . 
be obtained 

SFDP 


SIN 

TANH 

DETCS 
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Mpntif ic ation 

Log in 
LOGIN 


Purpose. 

To logout any previous user of this console, identify the 
new user, and initialize any system bookkeeping. 


Usage 

user : 
response : 

user : 
response : 


LOG I N probno name 
W TIME, 

PASSWORD 

private password 

probno progno LOGGED IN datel timel 
message of the day 


CTSS BEING USED IS id 



SHIFT MINUTES 


ALLOTTED 

USED SI 

INCE dai 

1 a tl 

utl 


2 at2 

ut2 


3 at3 

ut3 


4 at4 

ut4 


5 at5 

ut5 


LAST LOGOUT WAS 

date3 t 

i me3 

STORAGE DEVICE 

QUOTA 

USED 

DRUM 

DRQ 

DRU 

DISK 

DIQ 

DIU 

TAPE 

TPQ 

TPU 


probno is the user's problem number. 

name is the user's last name of which only the last 
six characters are used. 


TIME is the current time of day. HHMM.M 


password 


after typing PASSWORD, the system turns off 
the printing mechanism, if possible, so that 
the user may type his password with privacy. 


progno is the programmer number equivalent to probno 
name . 



datel is today's date. MM/DD/YY 
timel is current time of day. HHMM.M 


I 
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message of the day (optional) gives some pertinent 
information about the system. 

id is the name of the version of CTSS being used. 

atl-5 is the time in minutes allotted to the user 
for shifts 1-5 this month. Shifts 1 , 2, and 3 
are Monday through Friday; 9:00 A.M. - 5:00 

P.M., 5:00 P.M. Midnight, Midnight - 9:00 

A.M./ respectively. Shift 4 is weekend time 
from Saturday 9:00 A.M. through Monday 9:00 
A.M. Shift 5 is time used by FIB jobs. 

utl-5 total time used in each shift. 

date2 time2 are date and time when used time began 
accumu 1 a t i ng. 

date3 time3 are date and time of user's last LOGOUT. 

DRQ number of records on drum allotted to user. 

DRU number of records on drum used. 

DIQ number of records on disk allotted to user. 

DIU number of records on disk used. 

TPQ number of records on tape allotted to user. 

TPU number of records on tape used. 

If the user has 'urgent mail' from the system, login prints 

YOU HAVE URGENT MAI L 

before the response: 

probno progno LOGGED IN datel timel 

The user should print the file URGENT MAIL immediately after 

he is logged in. 
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Error messages 

1. NOT PROBLEM NUMBER. 

LOGIN COMMAND INCORRECT. 

The user has typed a problem number which is not 
poss i bl e. 

2. NOT FOUND IN DIRECTORY 

LOGIN COMMAND INCORRECT. 

The combination of the user's problem number/ name/ and 
password has not been found in accounting files. This 
printout contains what is not found (if it is the 
password, the printout says PASSWORD). 

3. probno name ALREADY LOGGED IN. 

LOGIN COMMAND INCORRECT. 

User is already logged in on another console. 

4. PARTY LINE GROUP NUMBER WRONG. 

LOGIN COMMAND INCORRECT. 

User's party line group, as found in accounting files, 
exceeds the maximum party group number (System or 
administrator error). 

5. PARTY LINE IS BUSY, PLEASE TRY AGAIN LATER. 

This is the result of one of the following conditions. 

a. Primary lines in user's party line group are 
filled, and user is not allowed to be standby. 

b. User's party line group number is zero, and 
user is not allowed to be standby. In other words 
this user may not be logged in at all. 

c. Maximum number of users for time-sharing has 
been reached, the user's party line group is 
either zero, or the primary lines for that group 
have been filled. 

d. Maximum number of users for time-sharing has 
been reached, and there are no standby users to be 
logged out. 

6. USER MAY NOT USE THIS CONSOLE. 

LOGIN COMMAND INCORRECT. 

According to the user's unit group, he is attempting to 
log in at a console he is not allowed to use. 

7. UNIT GROUP NOT FOUND. 

User's unit group number is not found in accounting 
files. 

8. ALLOTTED TIME EXCEEDED FOR THIS SHIFT - NO LOGIN. 
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The user s allotted and used time will follow this 
printout, same format as that of the normal login, 

except that the printed number of tracks used will be 
zero. 

9. IF YOU LOGIN YOUR FIB JOB WILL BE LOST 
DO YOU WANT TO LOGIN, 

A FIB job belonging to this user is currently running. 

f I" 16 types YES, his FIB job will be logged out and he 
will be logged in. If he types NO, he will not be 
logged in, and his FIB job will continue to run. 

Party Groups 


The party line group is a way of insuring that at any time 
during time sharing, a specified number of people in each 
party group can be logged in. 

Each user is assigned to a party line group; each party 
line group is assigned a specified number of primary lines. 
A record of each user's party line group number is kept in 
his entry in the time-accounting file UACCNT SECRET. A 
record of the number of lines assigned to each party line 
group is kept in the time-accounting file PRTYGP SECRET. 

For a party line group having N primary lines, the first N 
people belonging to that party line group who log in will be 
assigned primary lines. The next person belonging to that 
party line. group who attempts to log in is allowed to do so 
if the maximum number of CTSS users has not been reached. 
Ihis user is logged in as a standby. Standby users may be 
logged out to allow a primary user to log in. An example 
might clarify this. 


Suppose there are 5 lines assigned to party group 1 and 3 
lines assigned to party group 2. There may be a maximum of 8 
users of CTSS. Four users belonging to party group 1 are 
logged in and one user belonging to group 2 is logged in. 
Users A,B, and E belong to party group 1. Users C, D, and F 
to 2. User A logs in and gets the last primary line of 
group 1. B logs in and is made standby. C logs in and gets 
second primary line of group 2. E tries to login. The number 
or users = 8, and all primary lines in group 1 are assigned 
so E is not allowed to login. F tries to login and the 
situation is the same as for E. D tries to login. The 
number of user = 8, but there are only 2 lines from D's 
party group assigned, so B is logged out to make room for D. 

It should be noted that a user who is logged in as a standby 
can become primary while time-sharing, if a primary user in 
his group logs out. 

Party. line group zero has the notable line allotment of 0. 
That is, a user whose partyline group number is zero is 
always standby. 
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I dent i f i cat i on 
Log out 

LOGOUT , AUTOMATIC LOGOUT 
Purpose 

LOGOUT allows the user to terminate his use of the console 
without saving any machine conditions and also to express 
his opinion about the quality of the time-sharing service he 
received. The opinions thus collected are statistically 
processed to gain information about user satisfaction with 
different scheduling techniques. The automatic logout 
allows the system to terminate an inactive user or terminate 
all users for a system shut down in such a way that each 
user may later RESUME his program from the point of 
interruption. 

Us ag e 

LOGOUT: 


user: 
response : 


t i me 


datel 


probno 


progno 
XX. X 


N 


N = X 


N = 0 


N = 1 


N =2 


LOGOUT -N- 
W time 

probno progno LOGGED OUT datel timel 
TOTAL TIME USED = XX. X MIN. 

and timel are the current time of day. HHMM.M 
is today's date. MM/DD/YY 
is the problem number 
is the programmer number 
is the time used in minutes. 

(optional ) if N is omitted, no opinion of the 
service is expressed. If N is included, it 
should reflect as closely as possible the 
users satisfaction with response for this 
session for his particular application. 

The user has no opinion to express, (e.g., he 
logged in, then logged out without doing 
anything). 

The system response was totally unusable. 
Response was intolerably slow. 

Response was sluggish but not intolerable 
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N=3 Response was typical of what was expected. 

N=4 Response was better than expected. 

N=5 Response could not have been better. 

N=Anything else. A one sentence description of the 
choices of parameters Is desired. 

AUTOMATIC LOGOUT: 

response: WAIT/ 

AUTOMATIC LOGOUT 

Automatic logout may be initiated by the system. If the 
user is not in dead status/ a saved file will be created 
called LOGOUT SAVED. The program may be resumed at some 
later time by: 


RESUME LOGOUT 


or CONTIN LOGOUT 
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I den t i f i cat i on 

Foreground Initiated Background 
F IB,DELF IB 

Purpose 

With a minimum of user effort, the RUNCOM facility 
(AH. 10. 01) allows predescribed sequences of commands to be 
executed. The user of RUNCOM, however, must remain logged 
in and may not make any other use of his console until the 
completion of the sequence. 

The FIB facility allows the user to specify files which are 
to be executed by RUNCOM when the user is not logged in. 
The supervisor schedules a FIB job in the same scheduling 
queues as regular foreground jobs. 

Restrictions 

No FIB job will be run while its donating user is logged in. 
Auser who logs in during execution of one of his FIB lobs 
will cause that job to be automatically logged out. A user 
may initiate any number of FIB jobs. As one might expect, 
there is no way for FIB jobs to receive console input. 

U-sase 

To initiate a FIB job: 

FIB NAME 1 TIME 

NAM El is the primary name of a file NAME 1 BCD which 
is a list of the commands to be executed by 
RUNCOM as a background job. 

TIME is the maximum execution time limit in minutes 
which the user wishes to place on the job. If 

TIME is not specified, a time limit will be 
set by the supervisor. No FIB job will be 
allowed to exceed a certain maximum time; 
which is currently set as 5 minutes. A FIB 
job which exceeds its time limit will be 
"automatically logged out", and it may be 
restarted by the user. 

To delete a waiting FIB job: 

D ELF IB NAME 1 

Method 

FIB jobs are run one at a time on a f i rs t-come-f i rs t-se rved 
basis. A FIB job is run in the same scheduling queues 
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asforeground jobs but as the result of no console 
interaction, it moves to the lower priority queues. The FIB 
job is logged in; the list of commands are executed by 
RUNCOM; and when the list is exhausted or time limit is 
exceeded, the job is logged out. Calls to WRFLX cause 
writing into a file, $ $ $F I B OUTPUT, in the user's file 
directory. Calls to DEAD, DORMNT, RDF LX, COMFIL, and ATTCON 
cause FIB jobs to be automatically logged out. If a FIB job 
is logged out for any reason, it must be restarted bjy. the 
user . The FIB job running at system shutdown time will be 
run to completion or until it exceeds its time limit. If a 
FIB job is logged out because it exceeded its time limit it 
is logged out by ENDLOG so that as much as possible is 
saved . 

The user cannot be logged in while his FIB job is running. 
If he is logged in when his FIB job's turn to run comes, the 
FIB job is passed over and the next FIB job is tried. The 
job that was passed over retains its relative position in 
the list of FIB jobs until it can be successfully logged in 
or the user who initiated it deletes it. If the user's FIB 
job is running when he tries to log in, he will get this 
message : 


IF YOU LOG IN YOUR FIB JOB WILL BE LOST. 

DO YOU WANT TO LOGIN, 

If the user types YES, his FIB job will be automatically 
logged out, and login will continue to log him in. If he 
types NO, he will not be logged in, and his FIB job will 
continue to run. 

The user may initiate any number of FIB jobs. 
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Identi f ication 


AED - ALGOL Extended for Design 
D. T. ROSS - X5880 


Purpose 


A general purpose programming system including a compiler 
source language debugging facilities, and a library of 
subroutines. Thecompiler is especially suited to system 
programming, but includes algebraic statements, recursive 
functions, and mixed algebraic expressions for general 
purpose programming as well. The compiler language is an 
extended form of ALGOL-60, minus mu 1 1 i -d imens i onal arrays 
Some of the syntactic forms of ALGOL are modified, such as 
procedure def ini tion. Additional features include plex 
structure processing (a generalization of list processing) 
packing of data storage, and an input-string macro and 
synonym feature which includes conditional compilation. The 
subroutine library includes packages of routines for 
free-format input-output, for building of symbol tables for 
language processing, for plex dump and relocation, for "free 
storage" storage allocation, for use with the ESL display 
console, and for the "AED Jr." system, an experimental 
language processor. The AED command is the stable, tested 
version of the compiler. TAED is the experimental compiler, 
including new features in the checkout process. LAED is the 
special, extended version of the CTSS loader which contains 
additional features, such as loading a remote list of 
programs. The AED command contains additional options for 
source file conversion into extremely compressed or expanded 
block structured formats for ease of understanding. 

References 


MAC 

146 

MAC 

154 

MAC 

169 

MAC 

198 

MAC 

199 

MAC 

207 

MAC 

208 

MAC 

213 

MAC 

225 

MAC 

226 


AED-0 Programmer's Guide 
Warnings & Restrictions in AED-0 
"LOADER: A New Version of the 
BSS Loader" 

PLEX-DUMP & Relocation in AED-0 
Stack manipulation in AED-0 
"Internal Memos for AED Users" 
"Flash No. 10 - New CTEST2 
Command" 

"Flash No. 11 - AEDBUG Usage" 
Argument Checking for AED 
Availability of AED Jr. Systems 


Feldmann, Ross 
Fel dmann 
Wo 1 man 

Fox 

Coe 

Fe 1 dmann 
Fel dmann 

Fox 
Wa 1 sh 
Ross 
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I denti fi cation 

BEFAP - Sell Laboratories' 7094 assembly language 
O.C. Wright - xb004 

Purpose 

BEFAP is a version of FAP with a more powerful macro 
compiler and with the ability to handle compressed source 
decks directly (see CRUNCH). Its advantages are the 
abilities to edit larger files (via the alter feature with 
CRUNCH decks) and to produce more readable listing files. 
An i mined iate benefit is the ability to use and mod i f y 
languages under CTSS which were developed and written in 
bEFAP. (e.g./ bLUJl/ALWAC/ SNUBUL) 

References 

| bM CZb-6235 FORTRAN II Assembly Program(FAP) 

MAC 179 bEFAP command within CTSS R. U. Bayles 


Usa^e 


bEFAP NAM El -'(CRUN)'- -'(LIST)'- 

NAME 1 FAP is the name of the source file to be 
translated. Files NAME 1 BSS and. NAME1 . SYMTB 
will be created and any old versions will be 
deleted. 

(CRUN) specifies that the crunched file, NAM El 

CRUNCH, should be translated instead of NAM El 
FAP. 

(LIST) specifies that a listing file, NAM El BCD, 

should also be created. It will be a 

line-marked BCU listing file which may be 
printed on-line by the PRINT command or 

off-line by RUUEST PRINT or PRINT control 
car d . 

If both (CRUN) and (LIST) are specified, they 
must be in that order. 
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I dent i f i cat Ion 

COGO-90 - Coordinate Geometry Language 
D. Roos - X5056 


Purpose 

COGO is a language and_ programming system for solving 
geometric problems in civil engineering. 

References 


Research Reports: 

R64-12 COGO-90 : Engineering User s Manual 
R64-18 COGO-90: Time Sharing Version 

R64-5 The Internal Structure of COGO-90 


Roos, Miller 
Roos, Miller 
Roos, Miller 


Usage 


The system is activated by typing 
COGO. Data may be read fromthe 
remote console. The same options 


the time sharing command, 
disk or typed in via the 
are available for output. 


Mod 1 f i cat i ons 


The 

the 

are 


format of several COGO commands has been 
publication of the above manuals. The 


changed since 
revised formats 


READ/DISK NAME1 NAME 2 


Succeeding COGO commands are read from the disk file NAM El 
NAME2 . 


DELAY/PRINT N 


Succeed i ng 
where N is 


output is written on 
any number from 0 to 


the disk 

9. 


in file 


.TAPE 


N, 




CTSS PROGRAMMER'S GUIDE 


Section AH. 2. 04 


PAGE 1 


I dent i f i cat i on 

COMIT - Symbol manipulating and string processing 
Bob Fabry - X2525 


Purpose 

COMIT is one of several available string processing 
languages. It is very powerful for performing string 
manipulation/ such as substitution/ rearrangement and 
duplication/ on strings of alphanumeric characters e.g. 
natural language text. It is not so powerful on arithmetic 
facilities nor complex list structures. 


References 


MIT Press Introduction to COMIT Programming 

MIT Press COMIT Programmer's Reference Manual 

ACM Comm. Mar. 1963 "COMIT" 

MAC 156/CC237 COMIT operation in CTSS 

CC 178 Availability of COMIT 

CC 246 COMIT subroutines for generating 

Fortran programs 

CC 248 COMIT system under MIT's FMS 


V.H.YNGVE 

V.H.YNGVE 

V.H.YNGVE 

D.C.MATI ATOF 
FABRY/ YNGVE 
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I dent i f i cat i on 

DYNAMO - Model Simulation Language 
A. L. Pugh I I I - x4426 

Purpose 

DYNAMO Is a computer program for translating mathematical 
models from an easy- to-understand notation into tabulated 
and plotted results. The models may be modeled on any 
dynamic feedback system such as arises in business, 
economics, or engineering. The principal limitation on the 
model is that it be a continuous representation of the real 
world. As DYNAMO does not recognize individual items or 
events, models of job shops and the like cannot be tested. 
Persons familiar with both digital and analogue computers 
will find that DYNAMO in many ways behaves more like an 
analogue than a digital computer. 

References 

DYNAMO User 1 s Manual A. L. Pugh III, M. I. T. Press 

Industrial Dynamics Memo D-805 "Time Sharing DYNAMO User's 
Manual", A. L. Pugh III 

Usage 

DYNAMO NAME1 P R 

where NAME1 is the name of the model to be run (with 
secondary name MADTRN), and P and R are optional (order is 
also optional). The effect of these letters is described 
bel ow. 

P-Page Skip 

If the particular console being used has been ad justed so 
that the perforations are three lines above where the paper 
stops following a vertical form feed, this letter can be 
used to cause DYNAMO to skip to the top of a page rather 
than leaving four blank lines between pages. 

R-Rerun 

This letter cause DYNAMO to skip immediately to the rerun, 
even though there is a SPEC card included in the model. 

After all the runs and reruns have been processed by DYNAMO, 
the console operator is given the opportunity to specify 
additional reruns by typing the normal rerun information, 
with one exception. The RUN card, instead of preceding the 
rerun, follows the rerun information and signals DYNAMO to 
start to process that rerun. 
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When DYNAMO is expecting this rerun information it will type 

out 

PLEASE TYPE CHANGES IF RERUN DESIRED 

The user types the cards for a rerun just as he would for a 
rerun with the regular version of DYNAMO. He does not have 
to specify the card number of the card he is changing. Nor 
does he have to wait for the computer to type a card number 
or M as he does when using the INPUT and EDIT commands. The 
tab signifies a skip to Column 7. 

A feature of time sharing simplifies correcting typing 
errors. Should the user wish to delete a long line with 
several errors he may type a ? followed by a carriage return 
to start him at the beginning of a new line. 

If the user does not wish to rerun his model he should type 

QUIT 

If while DYNAMO is either printing or plotting the results 
of a run the user decides that he does not want any further 
output but would like to skip on to the next rerun, he may 
press the break button once and DYNAMO will proceed 
immediately to the rerun. 

Differences In Input 

Basically the input to the Time Sharing DYNAMO is the same 
as the regular DYNAMO. There are several minor restrictions 
which are introduced by the time-sharing system while other 
restrictions have been removed. 

1. As one has access to this model only through 
the console, the option to number the cards of 
a model now becomes a requirement. 

2. A continuation card has a different card 
number rather than having the same number as 
the card it continues. 

3. The contents of the identification card (the 
first card) are entirely optional. Columns 7 
through 36 of this card are copied into the 
page heading. 

4. The RUN card which is normally the second card 
i s now optional . 

5. The RUN number should be restricted to 5 
instead 6 characters. 

6. Because of the narrower page only nine columns 
are available for tabulating results instead 
of the former fourteen. 
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I den t i f i cat i on 

ESL display system (not a command) 
C. Garman - X5889 


Purpose 

To provide a graphical input and output facility with a 
limited real-time capability. Two 18 inch CRT S are 
provided for output. Input is from light pens, 

pushbuttons,, toggle switch banks, and other forms of 
analogue input. Real time rotation, translation, and 
magnification of appropriately constructed pictures is 
possible under program control. 


Ref e rences 


MAC 

122 

MAC 

125 

MAC 

166 

MAC 

201 

MAC 

202 

MAC 

217 


DEMON: ESL Display Console Demonstration Polansky 

Program 

ESL Display console Time Studies Polansky 

B-core system for programming ESL in CTSS Lang 
ESL Display console system manual Bayles 

Proposal to improve rotation matrix of ESL Stotz 
Operating Manual for the ESL Display Console Stotz, 

Ward 
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I dent I f I cat i on 

FAP - IBM 7094 machine language 
Programming staff 


Purpose 

FAP is the IBM MACRO-FAP assembly program for the 7094 
machine language code. It accepts all 7094 operation codes 
and the standard data defining pseudo-ops, as well as macro 
definitions. Input files may be line-marked or 
line-numbered. Four new pseudo-operations have been added 
to the time sharing version. 


References 

IBM C28-6235 
CC 201 
CC 217 


Fortran II Assembly Program (FAP) 
MIT version of FAP 
Abbreviated FAP 


Sal tzer 


U S 

FAP NAME1 —'(LI ST ) * — 

NAME1 FAP is the name of the FAP source language 
file which is to be translated. The files 
NAME1 BSS and NAME1 SYMTB will be created^ if 
the assembly is successful. _ Any previous 
versions of these two files will be deleted. 

(LIST) is an optional argument which instructs FAP to 
produce a line-marked listing file named NAME1 
BCD. This file produces a listing similar to 
the one produced by FAP under FMS when it is 
printed off-line by RQUEST PRINT or print 
control card or on-line by the PRINT command. 


the 

the 

the 


of 
of 
unless 


INSFRT pseudo-operation 

The pseudo-operation INSERT NAME will cause thecontents 
file NAME FAP to be inserted and assembled in place 
INSERT instruction. The entire file is inserted 
END card / signalling the end of the input deck, is 
found. Only one level of nesting 
INSERT may not be used within a file 
I NSERTed. 


is all owed; i . e , 
which is itself 


, an 
be i ng 


LSTNG pseudo-operation 

The pseudo-operation LSTNG controls console 
assembly listing. The first LSTNG card 
beginning with the next line. Alternate 
LSTNG turn this feature on and off. 


printing of the 
causes printing, 
appearances of 
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NOSEQ pseudo-operation 

The pseudo-operation NOSEQ prevents sequence checking of 
serialization in columns 73-80; i.e. no "SOURCE ORDER ERROR" 
diagnostics appear in the NAM El BCD listing file. 

NOLNK pseudo-operation 

The pseudo-operation NOLNK deletes the standard error 
procedure section of FAP. The linkage director, normally 
provided for all subprograms, is omitted, and calling 
sequences produced by CALL are shortened by two 
i nstruct i ons . 

I nput files 

Both line-marked and line-numbered files are acceptable as 
input, and files may be mixed (an INSERTed file need not 
con ta i n the same type record as the main input file). All 
input files, regardless of type, have the secondary name 
FAP. 

Records in line-marked files may contain tabs, which are 
interpreted by FAP. A maximum of 72 columns per card are 
assumed for line-marked records. 
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I denti f i cation 

GPSS - General Purpose System Simulator 
M. M. Jones - X587U 

Purpose 

GPSS is a simulation language that is easy to learn, use and 
debug. It automatically collects and prints many useful 
statistics. GPSS is particulary well suited for simulation 
of traffic flow models, such as communication nets, circuit 
models, computer systems, and queuing models. 

References 

HAC 14U Un-line Version of GPSS II M.M. Jones 

IBM B20-6346 General Purpose System Simulator II 
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I denti fi cation 

LISP - List Processing Language 
Wm Martin - X58 79 


Purpose 

LISP is a high-level list processing language, mathematical 
in character. Programs specify computation by recursive 
functions. The time sharing version contains functions which 
permit smooth interaction between Lisp and the time sharing 
environment. The language is used extensively in artificial 
i nte 1 1 i gence work. 

References 


MIT Press LISP Progammer's Manual 

Information METEOR: A LISP interpreter 
International for string transformations 
Information The Programming Language 

International 'LISP' 


MAC 

128 

Secondary Storage in 

LISP 

MAC 

129 

LISP Garbage Collector 

MAC 

134 

LISP Exercises 


MAC 

142 

LISP as the language 

for 



an Incremental computer 

MAC 

153 

Time Sharing LISP 


MAC 

206 

CTSS LISP NOTICE 


Usage 





Levi n 
Bobrow, 

Berke 1 ey 

Bobrow, 

Berkeley 

Edwards 

Mi nsky 

Hart 

Raphael , 

Lombardi 

Martin, Hart 

Hart 


LISP -NAME1- 

NAME1 DATA is a BCD file containing pairs of 
S-express i ons which will be initially read and 
executed by the LISP evalquote operator. If 
NAM E 1 is not specified, the file named LISP 
DATA will be read. 


LISTEN NIL - while executing data from the DATA file, 
if the doublet LISTEN NIL is executed, 
subsequent S-express i ons will be read from the 
console. When the atomic symbol STOP is 
typed, reading and executing pairs of 
S-express i ons will continue from the DATA 
file. 


Example: EXAMP 

DATA contains - 

DEF 1 NE 

(( 

)) 


LISTEN 

NIL STOP )))))))))) 


When the command LISP EXAMP is given, the 
functions are defined from the file and pairs 
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of S - express ions are read from the console as 
test cases. Typing STOP at the console will 
terminate the command. 
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Identification 

MAD - Michigan Algorithm Decoder 

University of Michigan; Barden, B. Galler,and R. Graham 
Programming Staff 

Purpose 

MAD translates algebraic statements describing algorithms 
into the equivalent machine instructions. The MAD language 
was originally based on ALGOL 58 with certain extensions and 
adaptations. It allows some more powerful logical operations 
than Fortran II. 

References 


MAD November 1963 (Reference Manual) 

MAD December 1964 (Reference Manual) 

CC 186 Fortran & MAD format Specifications Spall 
CC 213 Abbreviated MAD Corbato. . etc. 

RESTRICTIONS 

The extended features in the appendix of the De 
have not been implemented. 

Usa ge 

The current compiler implements the language as 
the MAD Manual of November 1963. However, a f 
and modifications have been made. 

MAD NAME1 -'(LIST)'- -'(SYMB)'- 

NAME1 is the primary name of the source file NAME1 
MAD which is to be translated. 

(LIST) requests that MAP create a line-marked 

listing file called NAME1 BCD which may be 
PRINTed on-line or ROUEST PRINT for off-line 
printing. 

(SYMB) requests that MAD produce a special symbol 
table named NAME1 SYMTAB which is used by 
MADBUG. (SYMB) also suppresses the normal 
on-line printing of length, entry point and 
transfer vector length. 

CHANGES: 

1. A new statement 

I NSERT FI LE ALPHA 

will cause file ALPHA MAD to be inserted in the 
compilation after the INSERT FILE statement. Only 


cember 1964 manual 


described in 
ew additions 
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one level of nesting depth of inserted files is 
allowed/ although any number of INSERT statements 
may appear in the higher level program. 

2. An addition has been made to the block 

notation in MAD. Formerly only the form 

A ... B or A, ... / B 

was allowed/ where A and B are variables. Now the 
second expression may be a constant, e.g., 

A ... 7 . 

See MAD Manual, November, 1963, page 16. 

3. A change has been made in MAD for defined 

operators. (See MAD Manual, November 1963, pages 

100-112.) This was needed due to the added feature 
of saving and restoring index registers 1,2 and 4 
in functions. The change was made to the . . RTN. 
operator. This is now a unary operator, i.e. only 
a B operand. The function of the B operand remains 
the same, that is, the address of the value to be 
returned to the calling program. The A operand is 
internally set to the address of the index 
restoring code. This address is designated "FF". 
Note the example on pages 110-111 of the November 
1963 manual. This should be changed to the 
fol lowing: 

..RTN. This symbol, which is obviously 
invalid in a statement, stands for the 
operation of placing the appropriate value(s) 
in the arithmetic register(s) and then 
returning from a function to its calling 
program. It is analogous to the right hand 
side of a substitution statement (the B 
operand) and then a transfer to a given 
address (there is no designation for this 
address within the triple ). As such, there 
is no result. As an example, if the result of 
a function were a double precision number, 
say mode 5, the following would be a 
reasonable definition. 

MODE STRUCTURE 4. .RTN. 5 

JMP * + 3, BT, * + l 

CLA B 

LDQ B+l 

TRA FF 

OUT ACQ 

END 

The address FF is the address of the index 
restor i ng code. 
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I dent i f i cat i on 

MADTRN - Fortran II to MAD translator 
Programming staff. 


Fortran II has not been implemented to operate with the 
time-sharing system. In order to allow users to operate with 
Fortran II programs/ the MADTRN translator is provided. A 
Fortran II source language program may be translated to MAD 
and then translated to the equivalent machine instructions 
by the MAD compiler. MADTRN does not always produce perfect 
results and, therefore, should not be used unless absolutely 
necessary. MADTRN assumes a working Fortran program and 
therefore MADTRN diagnostics are minimal. 

References 

IBM Fortran Reference Manual 

CC 188 MADTRN, A For t ran-To-Mad Language Translator Korn 

CC 186 Fortran and MAD Format Spec i feat i ons Spall 


MADTRN NAME1 OP 


NAM El 


0P=( LIST) 


0 P= ( S YMB ) 


is the primary name of the source language 
file named NAM El MADTRN or NAME1 OP if OP is a 
class name. 

The argument (LIST) will be passed on to the 
MAD compiler and the listing file named NAME1 
BCD will be created by MAD. 

The argument (SYMB) will be passed on to the 
MAD compiler and the file NAME1 SYMTAR will be 
produced to be used by MADRUG. 
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I dent i f i ca t i on 


SNOBOL - A String Manipulation Language 
M. Daggett, X4116 

Purpose 


SNOBOL is a programming language for the manipulation of 
strings of symbols. A statement in the SNOBOL language 

° f ?h rU I e - that ° pe r ates on symbolically named 
strings. The basic operations are: string formation 

pattern matching, and replacements. Facilities for integer- 
arithmetic, — ^ • ■ - integer 

i nc 1 uded . 


indirect referencing and input-output 


a re 


Ref erences 


Journal of the ACM, January 1964, pp. 
cc 255 SNOBOL Available as a 
CTSS commanc! 


21-30 

Daggett, 


Pouz i n 


1 
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I dent i f i ca t i on 

STRESS Command 
R. Logcher 

Purpose 

STRESS is a prob 1 em-or i ented language for structural 
engineering. In its present form it performs primarily 
structural analysis, although it is developing into a 
computer-aided design system. 

Reference 

MIT Press STRESS: A User's Manual Fenves, Logcher, 

Mauch,Reinschmidt 

Imp! ementat ion 

STRESS is currently a command in the CTSS system. It 
consists of a short starter program and a number of links. 
For normal operation, the links are accessible through the 
PUBLIC file with the names STR(n) LINK. 

For development purposes, the linking program has been 
written so that a user can be developing one or more links 
while using others from the PURLIC file. If a copy of a 
needed link exists in the user's file directory, that copy 
will be used rather than the one in the PUBLIC file. 

Mod i f i cat ions 

Two. statements have been added to the language in order to 
facilitate its use with time-sharing. 

READ (FROM ) (FILE) NAME1 NAME2 
READ CONSOLE 

READ (FROM) (FILE) reads the input from a 

line-numbered file (which may have been 

created by INPUT or ED). A single file should 
not contain more than a single problem 

specification (not beyond a SOLVE statement 
because, presently, all active files are reset 
to the beginning whenever a new link is 
1 oaded ) . 

NAME1 NAME2 are the names of the disk file to be 
read. The names must begin with non-numeric 
characters other than commas, signs, or 
periods. The file is renamed .TAPE. 1 for 
reading, but will be restored to NAME1 NAME2 
by a different READ, ( i . e . , READ NAME3 NAME4 ) 
or by the statement STOP which calls EXIT. 


1 
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NAME 2 Is assumed to be DATA if not given. 

READ CONSOLE transfers to read the input from the 

console. 

Return to input from any part of the process, any error 
detection, or a single interrupt causes control to be 
returned to the console. The word TYPE, is given to indicate 
that a line of input is expected from the console. 

NOTE : 

The statements INPUT and EDIT are now available. They will 
function in the same way as the supervisor commands but the 
existing data structure will be saved and control will 
return to the console after the FILE command. 
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I dent i f i cat i on 

BLODI - A BLOCK DIAGRAM Compiler 

Bell Telephone Laborator I es, Murray Hill, New Jersey 
V.A. Vyssotsky, Carol Lochbaum, and J. L. Kelly, Jr. 

Purpose 

BLODI is a compiler intended for use in simulating sampled 
data processing schemes. It accepts as input a description 
of a circuit block diagram, written in BLODI language. 

References 

The Bell System Technical Journal, Vol 40, pp 669-676, May, 1961. 
Bell Labs Technical Memorandum MM-61-123-4, February 10, 1961. 
Bell Labs Technical Memorandum MA-1276, March 20, 1963. 
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I dent! f i cation 

Generate line-numbered files 
INPUT, EDIT, FILE, TFILE 

Purpose 

Allows the user to create a line-numbered, 14 words per 
line, BCD file and edit such a file by specifying the line 
numbers to be modified. These files are appropriate input 
for many of the card-oriented subsystems i.e., FAP, MAD, 
MADTRN, STRESS, etc. 

Method 

In the INPUT mode, the command generates and prints the line 
numbers (sequential and incremented by 10) so that the user 
need type only the data. The line number becomes part of the 
line as columns 75-80. In the EDIT mode, lines may be 
deleted, replaced or inserted by manual typing of the line 
numbers. At FILE time, the EDIT requests are sorted by line 
number and the later requests override any previous requests 
for the same line number. 

Usage 

I npu t: 

user: INPUT 

response: 00010 

The user then types a card image per line, 
according to the format appropriate to the 
programming language being used. Tabs may be 
used to specify fields. The carriage return 
terminates a line and the next line number 
will automatically be printed (incremented by 
1U) . 

A line consisting of only a carriage return 
will terminate the automatic or INPUT mode and 
enter the manual or EDIT mode. In the manual 
mode the following conventions may be 
f o 1 lowed: 

1) A line number (all numeric) followed by 

a space or tab followed by the desired 
line allows the deletion, insertion, or 
replacement of a 1 i ne of that sequence 
number. If the line number is followed 
by a tab, the first field is blank. 

2) DELETE, 'nl'-^nZ 1 2 - where nl and n2 are 
previous line numbers. Lines nl thru n2 
will be deleted or just nl will be 
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deleted if n2 is not specified. (Note 
that the commas in this request are 
opt i ona 1 . ) 

3) SEQUENCE/ 1 nl 1 - 1 / de 1 ta ' - . The automatic 
mode is resumed starting with line 
number nl and subsequent incrementing by 
delta. If delta is omitted/ the previous 
increment is retained. (Note that 
commas are optional) 

4) A line consisting of only a carriage 
return resumes the automatic mode with 
the next line number after the last line 
of the file. 

5) FILE NAME1 NAME2 terminates EDIT and 
initiates the FILE command. 

6) QUIT signal terminates INPUT and EDIT 
and the input lines may be lost. (See 
next page . ) 

Edit: 

user: EDIT NAME1 NAME 2 


response : 

XXXXX 




XXXXX 

is the next line number 
line of file NAME1 NAME 2 . 

following 

the 

last 

EDIT 

establishes the automatic 

or INPUT 

mode 

and 


appends to the file 

conventions under INPUT. 

NAME1 

NAME 2 . 

See 


user: FILE NAME 1 NAME 2 -MODE- 

NAME1 is the primary name of the file 

NAME 2 is the secondary name and should be the class 
of language used during INPUT. 

MODE is the mode of the file: 0 is temporary/ 1 is 
permanent, 2 or R1 is read only Rl, 3 or R2 is 
read-only R2. If MODE is not specified, 
permanent is assumed. 

FILE creates a sequenced line-numbered file with 
the line numbers as right-adjusted sequence 
numbers in the corresponding card images of 
the file. If an older file of the same name 
exists in the user's directory, it will be 
replaced by the new file. Any corresponding 
NAME1 SYMTB and BSS files will also be 
deleted. No message is given regarding this. 
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TFILE is also recognized as a command in the manual 
mode. TFILE is used by system programmers for 
checking-out new versions of FILE. 

Error procedure for FILE: 

In most cases the following procedure should succeed: 

.Comments are printed explaining the cause of 
the error, and FILE calls DORMNT. 

.Type a SAVE command. If track quota is 
exhausted, give the extra parameter • t ' to 
create a temporary mode saved file. 

.Fix up whatever was indicated as the cause of 
the error (file mode, track quota, etc.) 

.CONTIN the SAVED f i le. 

LOGOUT Peculiarities: 

The FILE command deals with files which usually are of 
temporary mode. Consequently, they are lost on a 
LOGOUT. There is some possibility of losing both the 
old and the new files. This does not apply in the case 
of automatic LOGOUT where temporary files are saved. 

The following tips may be of some help to restart a 
FILE command after a LOGOUT break. 

.Before LOGOUT, if possible, change the mode 
of (EDIT FILE) and (FILE FILE) to permanent. 

.If (INPUT FILE) is not found, all the input 
lines typed from the console have been lost, 
and must be retyped. 

.If (EDIT FILE) is not found, rename the old 
fi le (EDIT FILE). 

.If (FILE FILE) is not found, try a FILE 
command, without going through INPUT. 
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I f i cation 

Context editor for card image files 
ED 

1 production 

ED is a command for editing 14-word BCD card image files 
within CTSS. The command is based on TYPSET (CC-244/ 
MAC-M- 19 3 by J. H. Saltzer) and many of the conventions of 
TYPSET are used by ED. Tabs are automatically interpreted 
for FAP/ MAD/ MADTRN/ LISP/ COMIT/ and ALGOLC i . e. , AED) 
programs. Tabs may also be set by the user for other 
purposes. Although line numbers may be generated by the ED 
command/ editing is done entirely by context. The ED 
command is offered as an alternate to the present INPUT/ 
EDIT and FILE commands. 


Usage 

The ED command is initiated with the following CTSS command. 

ED -NAME1- NAME 2 -NAME 3- 

NAME2 is the secondary name of the file to be edited or 

created and must be provided. NAME1 is the primary name of 
the file to be edited. If NAME1 NAME 2 is not specified/ ED 
will assume that a new file i s to be created and will start 
in the high-speed INPUT mode. If NAM El is provided/ the 

command will look for the file NAME1 NAME2. If the file is 
not found/ the high-speed INPUT mode will be entered. If 

the file is found/ the EDIT mode will be entered. 

If NAME3 is specified and the file NAM El NAME2 is found/ the 

subsequent FILE will create a file NAM E 3 NAME 2 and NAME1 

NAME2 will remain unaltered. Any arguments to the FILE 
request/ however/ will take precedence. 


HIGH-SPEED 1 NPUT MODE: 

When the user enters this mode / the ED command, will type 
"INPUT:" on the user's console. While the user is. operating 
in this mode/ the ED command will accept input lines, from 
the user 1 s console. Tabs will be interpreted automatically 
for each input line. backspace characters may also be used 
to move back one character position in the input line. No 
response is typed for input lines and as a result/ the us *-r 
may type successive lines as fast as he wishes. When the 
user types a line consisting only of a single carriage 
return, the ED command will place the user's console in the 
EDIT mode. 
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mi MOUE: 

When the user enters this mode the response "EDIT:" will be 
typed on the user's console. At this time the user may type 
requests to the ED command. All changes made to a file 
become effective immediately and as a result/ the user is 
able to make recursive modifications to his file. We may 
think of a pointer which is positioned at a line in the 

edited file, when the user enters the EDIT mode from the 

INPUT mode/ this pointer will be positioned at the last 
input line typed by the user. When the user starts the ED 
command in the EDIT mode/ the pointer is positioned before 
the first line in the old file. If the end of file is 
reached by an EDIT request/ the comment "END OF FILE REACHED 

dY:" is typed on the user's console followed by the request 

which caused the end of file to be reached. At this time 
the pointer will be positioned after the last line in the 
file. when in the EDIT mode, any line which is not a 
legitimate EDIT request will cause the comment "NOT A 
REuUEST:" to be typed on the user's console followed by the 
line which caused the error. In many cases it is possible 
for the user to stack EDIT requests. If one of the requests 
causes an error message to be typed/ any stacked requests 
will be ignored. This is done in case one of the stacked 
requests depended on the successful completion of the 
request in error. 

any number of initial tabs or spaces (including 0) may occur 
in a request line. Arguments and the request must be 
separated by at least one space or any number of tabs or 
spaces. wherever the argument is line image, however, tabs 
and spaces retain their normal significance. 

War ni ng: 

One interrupt level is set which returns the user to EDIT 
mode. Use it sparingly, as it can result in lost lines in 
files if used during any request which moves the pointer 
(FI ND, LOCATE etc. ) . 



CTSS programmer's guide 


Section AH. 3. 02 


PAGE 3 


EDIT REUUESTS 

REQUEST: 

ABBREVIATION 

RESPONSE: 

ERRORS: 


FIND LINE 
F 

none 

END OF FILE 


The FIND request is used to move the pointer forward from 
its present position to the line specified by LINE. LINE is 
a normal input line and may contain tabs and backspaces. 
This line is used as a mask for selecting the desired line 
in the edited file. Matching is done only on the non-blank 
characters specified in LINE. For example/ the request/ 


F ( tab )-( tab ) -ALPH a, 1 


might be used to 
LOOP 

REQUEST: 

ABBREVIATION: 

RESPONSE: 

ERRORS: 


find the 1 i ne, 

TIX ALPHA/1/4 

LOCATE string 
L 

none 

END OF FILE 


The LOCATE request is used to move the pointer forward from 
its present position to the first line which contains the 
entire character string specified by "string". The full 
line of 84 characters is scanned, so that "string" may 
specify line numbers. It is recommended that string 
include the leading zeros of the line numbers to avoid any 
undesired match with program constants. 


REQUEST: 
ABBREVI ATI UN: 
RESPONSE: 
ERRORS : 


NEXT I 
N 

none 

END OF FILE 


This request is used to move the pointer forward from its 
present po sition in the file. " I " specifies the numbe r of 
lines to be skipped over. If I is "0" or not specified, it 
is assumed to be "1" and the pointer will be moved to the 
next line in the file. If the NEXT request is given after 
the end of file has been reached, the po inter will be reset 
to the beginning of the file and moved " I lines f r om there. 


REQUEST: 
ABBREVI ATION: 
RESPONSE: 


DELETE I 
D 

none 
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ERRORS: END OF FILE 

The DELETE request will delete "I" lines from the file 
starting with the line at which the pointer is currently 
positioned. The uoi nter j_s. 1 ef t jLt the pqs i t i.O,n yaca - tfid izz 
the 1 ast 1 i ne deleted .ky. this request « If I >s "0" or left 
unspecified / only the current line will be deleted. 


REQOEST: 

ABBREVIATION: 

RESPONSE: 

ERRORS: 


PRINT I -L- 
P 

printed lines 
END OF FILE 


The PRINT request will print "I" lines from the file 
starting with the line at which the pointer is currently 
positioned. Opon completion of this request/ the pointer 
will be left pointing to the last line printed. If I is "0" 

or left unspecified, one line will be printed. Normally 
lines are printed without line numbers. If the character 
"L" is present in the PRINT request/ line numbers will be 
printed to the right of the printed lines. 


REQUEST: 

ABBREVIATION 

RESPONSE: 

ERRORS: 


RETYPE LINE 
R 

none 

none 


Tii is request will cause the line at which the po inter is 
currently positioned to be replaced by LINE. LINE is a 

no rmal input line and may co ntai n tabs and backspaces. T hs 
do i nter i s not moved Jay. th i S JLjL&UJLSJL* 


REQUEST: 
ABBREVI ATI ON: 
RESPONSE: 
ERRORS: 


TOP 

T 

none 

F I LE WORD COUNT ZERO 
NOTHING IN FILE 
I NPUT : 


This request will cause the pointer to be reset and 
pos itioned before the first line in the file. If the file 
is empty/ high speed input mode is entered. 


REQOEST: BOTTOM 

ABBREVIATION: B 

RESPONSE: INPUT: 

ERRORS: none 


This request will cause the pointer to be positioned after 
the last line in the file. upon completion of this request 
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the user's console will be placed in 
mode. All subsequent lines will be 
added to the end of the file. 


the high-speed INPUT 
treated as input and 


REQUEST: 
AdbREV I AT I UN : 
RESPONSE: 
ERRORS: 


INSERT or (C.R.) 
I 

INPUT: 

none 


This request will cause the user's console to be placed in 
the high-speed INPUT mode. All subsequent lines will be 
treated as input and inserted af ten the line at which the 
pointer is currently positioned. If the INSERT request is 
given imrnedi atl y following a TUP request, the inserted lines 
will be placed at the beginning of the file. 


REQUEST: INSERT line 

AbdREV I AT I ON : I 

Response none 

Errors: none 

The INSERT request may be used to insert a single 1 i ne 
without changing to the high-speed input mode. Line * s 
normal input line. It is inserted following the line at the 

present pointer position. 


REQUEST: CHANGE 

AbdREV I AT I ON : C 

RESPONSE: none 

ERRORS: END OF 


Qstr i nglQstr i ng2Q 1 G 
F l LE 


"0" or left unspecified. 


the current 


This request will examine "I" lines starting at the line at 
whi ch the pointer is currently positioned Upon completion^ 
the pointer will be left positioned at the last 
examined by this request. If I 
it is assumed to be "1" and only 
examined. The character "Q" 
or "Quote character" and may 
liCD set. "stringl" and 
character strings and may be 
character "G" (GLObAL) is 
stringl will be replaced by 


line will be 
is taken to be the delineator 
be any character in the 6-bit 
"string2" are arbitrary bCD 
of different lengths. If the 
present, every occurrence of 
string2. If "G" is not present. 


only the first occurence 
string2 in each examined 


of str i ngl will 
line. EXAMPLES: 


be replaced by 


line: 
r eques t : 
new line: 
r eques t : 
new line: 


ALPHA= ALPHA+ALPHA 
C ' ALPHA' BETA' 

6ETA= ALPHA+ALPHA 
C ' ALPHA' DELTA' 1 G 

6ETA= DELTA+DELTA 
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request: C 1 DELTA+ 1 1 

new line: BETA = DELTA 


REuUEST: 

ABBREVIATION 

RESPONSE: 

ERRORS: 


BLANK 1 i ne 
BL 

none 

none 


The BLANK request will put blanks in the current line 
wherever non-blanx characters appear in "line". For example 
'BL XXXXXX 1 will clear the label field of a line in a FAP 
f i le. 


REQUEST: 

ABBREVIATION 

RESPONSE: 

ERRORS: 


OVRLAY line 
0 

none 

none 


The uVkLAY request will place the non-blank characters of 
"line" into the corresponding position of the current line. 
Notice that only non-blank characters of "line" replace what 
was in the current line. For example in a FAP file, if the 
current line is 

TXI *+l 


then 

0 

EOF ( tab ) 

bbH 

C tab ) ( tab ) 

will produce 

EOF 

TXH 

*+l 


comment 
commen t 


REQUEST: VERIFY 

ABBREVI ATlONs VE 
RESPONSE: none 

ERRORS: none 


The VERIFY request sets the verify mode. In the verify 
mode, completion of any of the requests FIND, NEXT, LOCATE, 
OVRLAY, BLANK and CHANGE will cause the printing of the 
cu r r en t- po i n ter line. In addition, CHANGE will cause the 
printing of all changed lines. Requests may not be stacked 
while in the verify mode. 


REQUEST: BRIEF 

ABBREVIATION: BR 

RESPONSE: none 

ERRORS: none 
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The BRIEF request sets the brief or normal mode. Within the 
brief mode/ the FIND/ NEXT/ LOCATE/ QVRLAY/ BLANK/ CHANGE 
requests will give no response. 


REQUEST: 

ABBREVIATION: 

RESPONSE: 

ERRORS: 


CLIP 'ON' or 'OFF' 
CL 

none 

TRUNCATED: 


The request CLIP ON sets a mode such that any input line 
which exceeds column 72 will cause the message "TRUNCATED:" 
followed by the faulty line image. Any waiting input lines 
will have been deleted. Requests on which this may occur 
are FIND/ INSERT/ RETYPE/ QVRLAY/ BLANK and high-speed 
INPUT. The request CLIP OFF resets the mode . The normal 
mode is CLIP uN for all files except FAP files which are 
norma 1 1 y CLIP OFF . 


REQUEST: SERIAL N 

ABBREVIATION: S 

RESPONSE: none 

ERRORS: none 

This request is used to change the increment between line 
numbers of successive lines to the increment specified by 
the decimal integer "N". Initially/ this increment is set 
to 10 by the ED command. If N is "0" or not specified/ it 
is assumed to be "10". Lines inserted after a line with the 
line number "L" will be sequenced L+N/ L+2N/ L+3N/ etc. If 
the lines following the inserted lines have line numbers 
which are less than or equal to the line number of the last 
inserted line/ as many lines as necessary will be 
resequenced to insure that all line numbers are unique and 
in ascending order. For example/ assume that "N" is 2 and 
the user wishes to insert 0 lines after line 25 in a file 
that was previously sequenced by fives. The inserted lines 
would be numbered/ 27/ 29/ 31 ... 43. The lines previously 
numbered/ 30/ 35/ 40, 45 and 50 would be renumbered to x 45/ 
47/ 49/ 51 and 53 respectively. The remaining lines in the 
file would be unchanged. 


REQUEST: 
ABBREVI ATI ON: 
RESPONSE: 
ERRORS: 


COLON a 
CO 

none 

Illegal argument 


A colon Cor backspace on 1050) is a logical backspace 
anywhere eg./ 'ABC ::: DbCC.R.) is interpreted as 'DbC'. 
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The colon moves the character pointer back one but does not 
erase the characters over which it has moved. One should be 
careful in using this convention that the total number of 
characters does not exceed 84, as any extras will be added 
to the next line during INPUT, or result in a request during 
EDIT. 

The COLON request allows the colon character to be inserted 
as text. (They may also be 'CHANGE'd in as desired.) If 'a' 
i s T or TEST, all 1 will be treated as text except for the 
as the first character after a tab. If 'a' is 6 or 
BACKUP the normal mode will be reinstated and all will 

be backspaces. 


REQUEST: TABSET T1 T2 ... TN 

ABBREVIATION: TA 

RESPONSE: none 

ERRORS: ILLEGAL TAB SETTING 

Ti specify the columns at which tabs are to be set. Tabs 
must be set in ascending order and may not exceed column 84. 


REQUEST: FILE -NAME1- 

ABBREV I AT I ON: FL 

RESPONSE: Ready message from CTSS 

ERRORS: NO FILE NAME GIVEN 

or FILE WORD COUNT ZERO 
NOTHING IN FILE 
I NPUT: 

This request is used to terminate the editing process and 
write the new edited file on the disk. NAME4 specifies that 
the new file will be created as NAME 4 NAME2. If NAME4 NAME2 
is not specified, the old file will be replaced by the 

edited file or a new file NAME 3 NAME 2 will be created. If 

no name was given by the initial ED command or by the FILE 

request, an error message will be printed and the FILE 

request will be ignored. 

If a file to be deleted is in R1 mode, confirmation of 
deletion will be requested. If confirmation is denied or if 
file is R2 inode, the EDIT mode will be reentered with the 
pointer at the top of the file. 
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I denti fi cation 

Save present dormant program. 

SAVE/ MYSAVE 

Purpose 

Allows the user to preserve the current program and 
condition of the machine so that it may be continued at some 
later time by use of the RESUME/ CONTI N/ or RECALL or RESTOR 
commands. 


Os ase 

user: SAVE NAM El - ' t 1 - 

error: MEMORY BOUND ZERO/ NO SAVED FILE CREATED. 

NAM El SAVED BUSY. SAVE NOT EXECUTED. 

NAME1 SAVED is the name of the file to be created. 

MEMORY BOUND ZERO means that the user was in DEAD 
status and there was no program to save. 

NAME1 SAVED BUSY means that another user was 
referencing the file NAME1 SAVED (or perhaps 
the user himself forgot to CLOSE it). The 
SAVE ORor MYSAVE must be r epeated-per haps with 
a new NAME1. 

SAVE In addition to the core image and machine 
conditions/ SAVE will save the status of any 
active files so that they may be repositioned 
by RESUME and RESTOR. It will also save any 
command chain present. 

MYSAVE In addition to the core image and machine 
conditions/ MYSAVE will save the statu of any 
active files in the current file directory/ 
but will then switch to the user's file 
directory before creating the SAVED file. 
This is the version used by automatic logout. 
Resumption of the SAVED file from the user's 
file directory by RECALL or CQNTIN will 
perform the necessary switch of directories. 

' t ' if present, the mode of the file will be 
temporar y. 
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| denti f i cation 

Saving and renaming temporary file generated by RUNCOM 
SAVFIL, RERUN 


Purpose 

In order to preserve the user's core image and machine 
conditions as needed during a chain of commands/ RUNCOM 
generates a series of temporary mode SAVED files with 
primary names of the special form ...OOn when n-1,2,3, etc. 
The problem arises of preserving these files when a a RUNCOM 
is SAVED in midstream/ and desired to be CONTINued at a 
later time - either in a subsequent LOGIN session/ or after 
another RUNCOM. SAVFIL and RERUN are designed to preserve 
these f i 1 es . 


Usage 

SAVFIL NAM El 
RERUN NAM El 

SAVFIL works on the unbroken chain of SAVED files 
with primary names of the form ...QQi/ 
i = n, n-1/ . . . / 2/ 1 where ...00(n+l) SAVED does 
not exist. Working in decreasing value of n, 
it renames the file ...OOn SAVED to an unused 
name of the form $ $ $ 00 j and makes it permanent 
mode. Finally/ it appends the list of new 
names $$$Q0j to the file NAM El SAVED. 

REFUN restores these files to their original names 
and mode form the information continued in the 
file NAM El SAVED. NAM E 1 SAVED is unchanged. 

The recommended (and probably ONLY) way to use these 
commands is as follows: 

MYSAVE NAME 1 to save a RUCOM job. 

SAVFIL NAME1 


RERUN NAME1 to continue the RUNCOM at 

CONTIN NAM El any future time 


As automatic logout performs the MYS 
a good practice would be to 
immediately at one's next LOGIN/ 
CONTINue the job at a later time. 


AVE but not the SAVFIL/ 
i ssue a SAVF I L LOGOUT 
if it is des i red to 


Both SAVFIL and RERUN operate only in 
di rectory. 


the user's file 
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i cation 

Link to files in other U.F.D'S 
LINK, UNLINK, PERMIT, REVOKE 

Purpose, 

, t is possible for a user to define or „ creat ® * f 'Jo \t 
linkable mode so that other users may have access <• 

•S havlra to copy it into their own file directories. 
The author o? a linkable file may permit as many users as he 

lithes to link to his file. In order for one user to access 
w * h _ r uspr's file the author must first grant permission 
ro the user and the user must establish a link to the 
Once^a link has been established, the user has complete 
access U the file within the restrictions of the mode 
permitted by the author. 

Usage 


Grant permission: 
PERMIT NAME1 


NAME2 MODE 


PROB PROG . . . -PROBn PROGn- 


NAME1 


MODE 


PROB PROG 


the 


cur rent 
gran t i ng 
NAME2 need 
be a 


NAME2 is the name of the file in 
file directory to which the author is 
linking permission. The file NAME1 
not exist, may exist in any mode, or may 
link pointer in the current file directory to 
a file or link pointer in some other 
Linking permission, therefore, may 
to any file to which the current 
has access or may have access 
PERMIT does not actually 


d i recto ry . 
be granted 
file d i rectory 
in the future, 


establ i sh a link. 

(octal) is the mode which the author wishes to 
permit for the file. During the 
process, this mode will be 'or'ed with any 
other modes in the chain of links to determine 
the final mode. Any mode w i th i n the ( ch a. n a f 
links which does not contain the LINKABLE 
mode will terminate the chain. 


specifies the problem number and P 
number of the user to whom the ti 
NAME 2 is being permitted, 
all problem numbers are implied. . 
or 0, all programmer numbers are implied. 


programmer 
whom the file NAME1 
I f PROB i s * or 0, 
If PROG is * 




T 
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Withdraw permission: 

REVOKE NAME1 NAME 2 PROB PROG ... -PROBn PROGn- 

REVOKE withdraws the linking permission for file 
NAME1 NAME2 of the current file directory from 
the user PROB PROG. Any link which may have 
been formed is also removed. 

Form a link: 

LINK NAME1 NAME 2 PROB PROG -NAME3- -NAME4- 

LINK establishes a link in the current file directory to 
the file NAME1 NAME2 in the file directory of PROB 
PROG. The file may be given a different name in the 
current file directory, if desired, by specifying NAME3 
NAME4. If NAME4 is not specified, NAME2 will be used as 
the class name. NAME3 NAME 4 is the name of the file in 
the other directory and NAME1 NAME2 is the name of the 
file in the current file directory. 

If permission has not been granted or if the file does 
not exist or is not of linkable mode, the link cannot be 
established. Links may be established through any depth 
of file d i recto ri es . 

Remove a link: 

UNLINK NAME 1 NAME2 NAMEln NAME2n 

UNLINK will remove the link from the current file 
directory for file NAME1 NAME2 . This in no 
way affects the permission. 

NAME1 NAME2 must be the name by which the file is 
known in the current file directory. 


Me t hod 


Two files in the system file directory (M1416 CMFL02) 
contain the permission and linking information. The PERMIT 
FILE contains the information of NAME 1 NAME2 PROB and PROG 
of the author and MODE as the full file description with the 
PROB PROG of the user to whom permission is being granted. 
The LINK FILE contains the same information about files to 
which the links have actually been formed. These two files 
are line-marked BCD linkable files which may be LINKed and 
PRINTed by any user. 
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I denti f ication 

Combine seldom-used files 
ARCH I V 

Purpose 

To combine files which are not frequently used so that the 
single archive file occupies fewer tracks than the many 
smaller files. The average saving is half a track per file. 
Individual files may be combined/ listed/ printed/ deleted 
and recreated. 

Restrictions 

Files of any class or secondary name may be archived/ 
however, only files of one class may be combined into a 
single archive file of the same class. 

Line-marked files should not be ARCHIVed. 

Files to be deleted are deleted by the standard convention 
of DELETE which are here restated under Method. 

UL&flgS 

ARCHIV KEY NAM El NAME2 F I LI ... F I Ln 

KEY = C: Combine files F I LI NAME2 ... F I Ln NAME2 into 
an archive file NAME1 NAME2. Any old files 
NAME1 NAME2 will be deleted/ if possible. 
FIL's are not deleted from the user's file 
d i rectory. 

KEY=P: Print file(s) FIL1 ... F I Ln which is (are) 

contained in archive file NAME1 NAME2. Only 
card image BCD files may be printed. 

KEY=T: Print a table of contents of archive file 

NAM El NAME2 . 

KEY = D: Delete FI LI from the archive file NAME1 NAME2. 

This involves creating a new archive file and 
deleting the old one with the standard hocus 
pocus of deleting. 

KEY=X: Extract and copy FI LI from archive file NAME1 

NAME2. The copy is named FI LI NAME2 and any 
old copies are deleted. 

KEY=R: Replace FIL1 in the archive file NAME1 NAME2 

with a copy of the file F I LI NAME2. This 

involves creating a new archive file and 
deleting the old one. If no F I LI exists 

within the archive file/ a message is printed 
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and the command is executed as ARCHIV C NAME 1 
NAME 2 NAM El FI LI. 


Method 

In combining files, the last line of each file is augmented 
by enough blank words ( bQbU6l)606U60) 8 to make the number of 
words in the file a multiple of 14. between the files is 
inserted a 14 word line consisting of six carriage returns 
( 555555555555) 8 followed by the name of the file (12 
characters) followed by 06 blanks. Thus if an archive file 
is printed with PRINTF, the component files will be 
separated by six blank lines. 

Whenever ARCHIV creates a new file, it is first named " 

" and is of temporary mode. After this file is created, 

the file which it replaces, if any, is deleted and file 

" ..." is renamed and the mode changed to permanent 

(or R1 if it is replacing an R1 file). 

Files to be deleted are handled in the standard DELETE 
manner, i.e., verification is requested for R1 mode files 
and R2 may not be deleted. If a file cannot be deleted, 
ARCHIV accomplishes nothing. 
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Identification 

Compress BCD files 
CRUNCH 

PV . r P. Q .&£ 

To compress a BCD file in such a way that it occupies less 
disk space and/ incidentally/ is in a form acceptable as 
input to BEFAP. 

Usage 

Crunch : 

CRUNCH 'CR' NAME1 -NAME2- -'PUNCH'- -'72COLM'- 

CR directs the crunching of file NAME1 NAME2 into 
a file NAME1 CRUNCH. If NAME2 is omitted it is 
assumed to be FAP. 

PUNCH directs the crunching of file NAME1 NAME2 into 
a file NAME1 PUNCH which is in a form suitable 
for BPUNCH with RQUEST. 

72COLM directs the crunching of only columns 1-72 of 
the source file. This results in additional 
space saving and the sequence numbers may be 
reconstructed during uncrunching. 

The order and presence of PUNCH and 72C0LM are 
opti onal . 


Uncrunch : 

CRUNCH 'UN' NAME1 -NAME2- -'PUNCH'- -'NUMBER'- -MAJ- -SEQ- 

UN directs the reconstruction of the source file 
NAM El NAME 2 from the crunched file NAME1 
CRUNCH. If NAME2 is omitted, it is assumed to 
be FAP. 

PUNCH directs the uncrunching of NAME1 PUNCH rather 
than NAME1 CRUNCH. 

NUMBER directs the resequencing of the source file 
NAME1 NAME2 . In the absence of MAJ and/or SEQ, 
the first three non blank characters of NAM El 
will be used in cols 73-75 and sequencing will 
begin with zero with increments of ten. The 
order of 'PUNCH' and 'NUMBER' is optional. 

MAJ if specified in conjunction with 'NUMBER', the 
first three non blank characters are placed in 



PAGE 2 


CTSS PROGRAMMER'S GUIDE 


Section AH. 4. 02 


columns 73-75 of the source file NAM El NAME 2 . 

SEQ if specified in conjunction with ' NUMBER ' 
causes sequencing to begin with SEQ. The fixed 
i ncrement i s ten. 

Fr int: 


CRUNCH 'PR' NAM El -'PUNCH'- -'NUMBER'- -LABEL- -SEQ- 
PR directs the printing of NAME 1 CRUNCH 


PUNCH 


directs the printing of NAM El PUNCH 
than NAME1 CRUNCH. 


rather 


SEQ 


is numeric to specify begin printing with 
of sequence number SEQ. 


card 


NUMBER 

LABEL 


SEQ begins the printing with alter number SEQ 


is alphanumeric to specify begin 
card containing LABEL in columns 
sequence numbers will appear on 
the listing. 


pointing with 
1-6. The 
the left of 


NUMBER 


LABEL begins the printing 
with LABEL in cols. 1-6. The 
will be printed on the left of 


with the card 
alter numbers 
the listing. 
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intif ication 


List contents of User's File Directory 
LISTF 


To provide the user with a table of contents of his 
including date last used, mode, and the number of physical 
record used. Information may be requested for specific 
files or files used before a certain date. 

Method 

Among the he data available in the file directory for each 
file are the dates last used, the file name and mode, and 
the number of records used. LISTF will type, this data, 
selectively, as well as type a heading line giving the total 
number of files and records used. 



Table of Contents: 


LISTF - ' REV ' - 


LISTF will list, in reverse chronological order by 
date last used, the available data for each 
file in the current file directory. 

REV (optional) directs the listing to be in 
chronological order rather than reverse 
chronological order. 


Spec i f i c file: 

LISTF NAME 1 NAME 2 

LISTF will list the available data for file NAME1 
NAME2. Either NAME1 or NAME 2 may be * , in 
which case all files with the specified 
primary and secondary name will be listed. 


Before a date: 

LISTF MM DD YY 

LISTF will list the available data of all files last 
used on or before the date MM/DD/YY. 

MM DD YY are numeric digits expressing 
date. 


a 


the des i red 
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I den t i f i cat i on 

Print BCD card image files 
PR INTF 

Purpose 

To print the contents of BCD card image files 
(line-numbered) either from the beginning of the file or 
from some specified line number. 

Usage 


PR INTF NAME 1 NAME 2 -SEQ- 


PRINTF prints the contents of file NAME1 NAME2 by 
printing first characters 73-80 and then 
characters 1-72 so that the line numbers will 
appear on the left. 

SEQ specifies the numeric portion of the columns 
73-80 of the initial line to be printed. If 
SEQ is omitted, the beginning of the file is 
assumed. If SEQ does not match any line 
number, the next higher line number in the 
file will be used . 
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I dent i f i cat i on 

Print a BCD file 
PRINT 

Purpose 

To print the contents of a BCD file, either 1 ine-numbered or 
1 i ne-ma r ked . Specific lines and special format may be 
requested . 

Restrictions 

The maximum record length is 132 characters. 

Usage 


PRINT NAME1 NAME 2 -LINES- -FIELDS- 

PRINT will normally print line-numbered files as 
characters 73-80, blank, then characters 1-72. 
Line-marked files will be printed characters 1 
to the last with 132 characters per line of 
type . 

LINES (optional) may specify which lines or records 
should be printed if other than the initial 
line is desired. The specification may be one 
of three forms: 

1) s from s thru the end of file 

2) s 'TO' e from s thru e 

3) s 'THRU' e from s thru e 

where s and e are decimal digits which are 
interpreted as 1 ine-numbers or record numbers. 
Line-numbers are matched against the 
right-most numeric field of card image files. 
Record numbers identify va r i ab 1 e- 1 ength 
records by their numeric order, beginning with 
1 . 

Line-numbers are assumed for card image files 
and line-marked files of 14 words of 
information. The mode is switched to record 
number upon encountering any line-marked 
record different from 14 words (no switch back 
possible). Using THRU instead of TO forces 
the record number mode. 

FIELDS may be specified only if LINES is not void 
(may be 0 or 1). FIELDS is any number of 
pairs of decimal numbers from 1 to 132 i.e., 

al bl a2 b2 an bn. The printed line, will 

be a concatenation of every field specified by 
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TITLE 


DREAR 


the position in the record read from the file/ 
as from the ai character thru the b\ 
character . 

Ai and bi may be in any order, and the fields 
are independent of each other. A field may be 
partly or entirely repeated and also printed 
in reverse order . If a specification field 
exceeds the length of a record, the outside 
characters will be set blank. If the last bn 
is omitted, it is assumed equal to an, a 
single character field. 

A line of i nf ormat i on will be printed to 
provide file name, user identification, system 
name, _ date and time if and only if the 
printing is to begin with the first record of 
the file and TO or THRU is not specified. 

An interrupt signal will stop the printing and 
terminate the command. The command terminates 
by calling CHNCOM. 
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Identification 

Print contents of a file in octal 
PRBIN 

Purpose 

Print on the user's console the contents of a file in octal. 
It may be used to examine SAVED or BSS files or BCD files 
which might contain illegal characters. 

Usage 


PRBIN NAM El NAME 2 — 1 0 * - -N- -R- 

U (optional) the presence of 0 indicates that 

the following arguments are expressed in octal 

rather than decimal. 

N (optional) specifies the first word to be 

printed. N may be specified as 1 or omitted 
and assumed 1. 

K (optional) Printing will be grouped into 
blocks of R words (5 words per line) where 
each block is labeled with its rank/ i.e./ N/ 
N+R/ N+2R etc. Naturally if R is to be 
specified/ N may not be omitted. If R is 
omitted/ it is assumed 10 (or 8 if 0 is 

specified). R may not exceed 40. 


PRBIN terminates by calling CHNCGM. 
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Identi f i cation 

Print summary of BSS files. 

PRBSS 

Pp.r.pas.a 

To print a summary of information about the program in a BSS 

file or about the programs if the file is a library file. 

Usage 

PRBSS NAME 1 -PROG- 

PRBSS prints the summary of information about the 
programs in file NAM El BSS/ possibly three or 
more lines per program. 

1st line: Entry names and their relative locations 

2nd line: Common, program, and transfer vector 
1 engths 

3rd line: Names in the transfer vector, if any. 

PRUG (optional) specifies the program entry name 
with which printing should begin. If PROG is 
omitted, printing begins with the first 
program in the file. 

BREAK A single interrupt terminates the command. 
PRBSS terminates by calling CHNCOM. 
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Irientif ication 

Pr i nt SAVED file 
SDUMP 

Purpose 

To print the machine conditions and/or locations within a 
SAVED file. 

Usag e 


SDUMP NAM El 

The machine conditions of file NAME1 SAVED 
will be printed on the user's console. 

SDUMP NAME1 LOC N 


The contents of N consecutive 
beginning at octal location LOC/ of 
image contained in file NAME1 SAVED 
printed on the user's console. All 
are typed in octal with mnemonics, 
all zero are omitted. The decimal 
may not exceed 1000. 


1 ocat i ons 
the core 
will be 
regi sters 
Lines of 
nteger N 


1 
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I dent i f i cat i on 

Comb i ne files 
COMBI N 

Purpose 

The COMB I N command combines several files of the same 
secondary name into a new file/ also of the. same secondary 
name. The format of the files is not significant. 

Usage 

COMB I N SEQ NAME1 NAME2 FILl...FILn 

COMB I N will combine files FIL1 through F I Ln of 
secondary name NAME2 into one file NAME1 NAME2 
within the current file directory. If any FIL 
cannot be found/ the NEED-USE convention will 
be followed (see Section AH. 7. 01). Within the 
USE process/ an * for a corresponding FIL 
means that FIL should be ignored. The 

combining will not begin until all FIL's are 
accounted for. FIL's are not deleted. 

SEQ is a decimal number of 1-4 digits. The numeric 
sequence field begins with SEQ x 10 with 
leading zeros to complete the numeric field or 
with the most significant digits lost if SEQ x 
10 exceeds the numeric field width. Sequencing 
is done by incrementing the numeric field by 
10. If SEQ = '*' or if NAME 2 is 'SAVED', 'RSS' 
or 'CRUNCH', no sequencing will take place. 

The sequence field (characters 73-80) may be 
composed of 2-5 numeric characters and 3-6 
alphabetic characters. The numeric field width 
is determined by a scan of the first line of 

F I LI from right to left, beginning with 

character 78, looking for the first nonnumeric 
character (blanks are treated as numeric 
zeros). The numeric field width and the 

alphabetic field width will remain fixed 
through the remainder of the command. The 

alphabetic information is obtained from each 
line of the FIL's. Note that the numeric field 
width will be at least 2 and not more than 5 
characters wide. 

EXAMPLES: 

If characters 73-80 of the first line of F I LI are 
ABC123GH and SEQ = 1, the new sequence for NAME1 
NAME2 will begin with ABC00010. 
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If the first line contains Abbbhbbb and SEQ = 1, 
the new sequence will begin with AbbOOOlO. 

If the numeric field overflows, a message will be 
printed, "SEQUENCE FIELD OVERFLOW", and sequencing 
will continue from 0. 

Line-marked files composed of 14-word lines may be 
sequenced. If a line of more than or fewer than 14 
words is encountered, sequencing is stopped and 
not resumed during execution of the rest of the 
command. A message is printed, "SEQUENCING STOPPED 
AT xxxxx". 
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I den t i f i cat i on 

Subd i v i de files 
SPLIT 

Purpose 

The SPLIT command divides or splits a specified file into 
one or more separate files of the same class. Either BCD or 
binary files may be SPLIT. 

Usage 

SPLIT NAME1 NAME2 MODE A1 SI A2 S2 . . . AN SN 

NAME1 NAME2 is the file to be SPLIT. In case NAME1 
NAME 2 cannot be found, the NEED-USE convention 
if followed as in the LOAD command (Section 
AH. 7.01) . 

Ai are the new files to be created, with the 
secondary name NAME2. All previous copies of 
new files are deleted, if possible. Any Ai may 
be replaced by if the file delimited by 

S(i-l) and Si is not wanted. Any Ai may be 
NAME1 . As the original file will not be 
deleted until all splitting is completed. 

Si are the numerical dividers of the file in 
order of appearance as the file is scanned 
only once and are interpreted, depending on 
the mode, as line number, record number, or 
number of words. The Si (th) record (or words) 
belongs to file Ai unless Si falls between 2 
sequence numbers, in which case the file is 
split between them. 

e. g. If Nj .LE. Si .L. N(j+1) where N is 

sequence number in NAME1. 

then file Ai ends with Nj and file A(i+1) 
beg ins with N(j+1) 

Sn may be omitted if An is to go through the end 
of NAME 1 . 


MODE: 


There are three kinds of files which may be SPLIT: 

1) Line-numbered - BCD card images (14 words) 
with numeric sequence number in column 76-80. 
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2) L i ne-marked or variable length records 
preceded by an extra word which contains the 
word count of the record. 

3) String - no obvious record divisions. 
Records rnay be treated as 14 word records or 
by external word count. 


MODE is an optional argument which may be inserted on either 
side of NAM El NAME2 . 


Record number mode assumes 14 word records, unless they are 
line-marked, and numbers them sequentially starting with 1 
This mode may be requested by the MODE argument (RCNO). 

Word count modesplits strictly by a count of the words, 
including any line marks present. This mode may be requested 
by the MODE argument (WDCT). 


If no mode is specified, it is assumed to be line numbered. 


If, at any time, a record is encountered which 
appear to be a regular BCD card image (e.g. not 
long or non-numeric in columns 76-80) a change is 
If search is still being made for SI (no splitting 
place), the mode is changed to record number, if 
and the search continues. Otherwise, splitting is 
the rest of NAME1 is placed in a temporary file 
appropriate comment is made. No other changes of 
occu r . 


does not 
14 words 
attempted . 
has taken 
poss i b 1 e 
stopped , 
, and an 
mode can 
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I dent i f i cat i on 

Change the mode or the name or delete a file 
CHMODE, RENAME/ DELETE 

Purpose 

To change the mode or the name of a file or to delete a 
file. 

Usage 

Delete: 


DELETE NAM El NAME2 NAMEln NAME2n 

Delete all versions of files NAMEli NAME2i 
from the current file directory/ if possible. 
R2 mode files may not be deleted and the 
following message is printed: 

★ATTEMPT TO DELETE FILE IN READ ONLY MODE. 

Attempts to delete R1 files results in the 
following message: 

NAMEli NAME2 i R1 MODE. DO YOU WANT TO DELETE \J 
Type either yes or no after the comma and hit 
carriage return. If for any other reason a 
file cannot be deleted/ a message is printed. 

NAMEli is the primary name of a file to be deleted. 

If NAMEli is */ all files of secondary name 
NAME2i will be deleted. If NAME2 is also */ 
no files will be deleted and the message "NO 
FILE WITH SECOND NAME * FOUND" will be 
printed. 

NAME2 i is the secondary name of a file to be deleted. 

If NAME 2 i is */ all files of primary name 
NAMEli will be deleted. 

Change mode: 

CHMODE NAME1 NAME 2 M0DE1 ....NAMEln NAME2n MODEn 

MODE must be 0/ 1/ 2/ 3/ J, P, R1 or R2. The mode 
of the file in the current file directory will 
be changed to MODE/ If possible. R2 mode 
files may not be changed and the following 
message is printed. 

★★TRIED TO RENAME READ ONLY CLASS 2. 

If the mode can not be changed for any reason/ 
a message Is printed. 
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NAME 1 i NAME 2 i - The same * convention is used as in 
the DELETE command. 


Rename : 

RENAME NAME1 NAME2 NAME3 NAME4 .... NAMEln NAME2n NAME3n NAME 4 

RENAME change the file name NAME1 NAME 2 to the name 
NAME 3 NAME4 . All other files NAME3 NAME4 will 
be deleted before renaming NAM El NAME2 . The 
deleting of NAME3 NAME4 has the same options 
and messages as under DELETE. If NAME3 NAME4 
cannot be deleted or if NAME1 NAME2 is R2 
mode/ no names are changed and a message is 
pr i nted. 

NAMEli is the NAME 3 i must be and all files of 

secondary name NAME2 are changed. 

NAME2 i is then NAME4 i must be and all files 

of primary name NAME1 are changed. 

NAME4n missing/ is assumed to be NAME2n . 
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Identification 

Common files 

COMF1 L, COPY, UPDATE 

Purpose 

A group of common files is assigned to programmers working 
on the same problem number. The COMF1 L command allows the 
user to switch the current file directory to begone of the 
common file directories or to switch back to his own. The 
UPDATE command allows the user to transfer one of his files 
into one of the common file directories. The COPY command 
allows the user to copy a file from a common file directory 
into his own file directory. 

Usage 
Comf i 1 : 

COMF1 L -N- 

N specifies the file directory desired as 0, 1, 

2, 3, 4. 0 signifies the user's file 

directory. If N is omitted, it is assumed 
zero. 

COMFIL switches the current file directory to N so 
that all subsequent commands will refer to 
directory N. Temporary files created in common 
files 1, 2, 3, or 4 will be lost on switching 
back to the user's directory or to another 
common file directory. 


Copy : 


COPY N NAME1 NAME 2 . . . . NAME In NAME2n 

COPY transfers files NAME1 NAME2n from common 

file directory N into the user's file 
directory. Any files of the same name in the 
user's directory will be deleted by the DELETE 
conventions after the successful copying of 
the new files. Files keep the same names but 
are always created in permanent mode. 

N may be 1, 2, 3, 4, S. S allows copying from 
the system file directory which contains the 
BSS foreground library and the saved version 
of public commands (with secondary name 
TSSDC . ) 
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Update: 


UPDATE N NAME1 NAME2 .... NAMEln NAME2n 

N is the user's common file number 1 , 2, 3, or 

4. 

UPDATE transfers files NAM El . . . NAME 2 n from the user's 
directory to the specified common file. Files 
keep their same name and mode. All previous 
versions in the common files are deleted by 
the DELETE conventions only after successful 
updating. The files in the user's directory 
are unchanged. 
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I den 1 1 f i cat I on 

Library file 
EXTBSS/ UPDBSS 


Purpose 


A library file may be created by combining programs in BSS 
form. The program loaders can search this kind of file to 
find missing programs. The housekeeping of these files can 
be done by EXTBSS and UPDBSS. 

Usage 

Extract : 

EXTBSS NAME 1 -NAME3- PROG 

EXTBSS will extract from the library file NAME1 BSS 
the first BSS routine with the entry PROG and 
create a file NAME3 BSS. Older files of NAME3 
BSS are deleted/ if possible. NAME1 BSS is 
unchanged . 

NAME3 If NAME3 is omitted (only 2 arguments) the 
newly created file will be PROG BSS. Omission 
of both arguments causes the printing of 
instructions for the use of the command. 

Update : 


UPDBSS NAME 1 NAME 3 -PROG- 


UPDBSS searches the library file NAME1 BSS for the 
first BSS routine with the entry PROG and 
replaces that routine with the entire file 
NAME3 BSS. This is accomplished by creating a 
new file NAME1 BSS and deleting the old, if 
possible. If NAME1 BSS can not be deleted/ no 
updating is accomplished. 

PROG If PROG is omitted/ the entry name is assumed 
to be NAME3. A main subprogram is designated 
by (MAIN). If no entry PROG can be found the 
message "PROG NOT FOUND IN LIB NAME1" will be 
printed and no updating will be done. 

NAME3 If NAME3 is '*'/ the routine with entry name 
PROG is deleted from NAME 1 BSS. 


% 




: 
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I denti f i cation 

Off-line processing 
RQOEST 




# 


Purpose 

Requests may be submitted to the dispatcher to print or 
punch current files, or send a current file to the other 

machine for reloading and updating. |,1d ^ nt * 
reauests may be submitted as punched control cards (see 
Section AE.l) or the RQUEBT command from the console will 
prepare a file called 00TP0T RQOEST. The control cards and 
the 00TP0T RQOEST files are processed several times a day by 
a background job called the disk editor. 


Usage 


XX = PR I NT : 


RQOEST XX NAME 1 NAME 2 OP 

The BCD file NAM El NAME 2 is printed off-line. 
If the file is not line marked, a blank word 
is inserted at the beginning of the line to 
insure single spacing and the first 84 
characters of the record are printed. If the 
file is line-marked, the first character is 
the carriage control character and the next 
131 characters are printed. 


XX=DP0NCH : 


The BCD file NAM El NAME 2 is punched off-line. 
If the file is line-marked, just the first 80 
characters per line of data will be punched. 


XX=B PONCH : 


The binary card image file NAM El NAME 2 will be 
punched off-line. The 7-9 punch and checksums 
should already De included in the card image 
file. 


XX=7P0NCH : 


The file NAM El NAME 2 Cof any format) will be 
punched off-1 i ne in a special card format 
which may be reloaded by the disk, loader to 
reproduce the file exactly. The file is not 
deleted from the user's directory. 


XX=UELETE: 

XX=CHM0DE : 


The file NAM El NAME 2 will be deleted from the 
current file directory. 

The mode of file NAM El NAME 2 will be changed 
to OP. UP may be 0,1,2, or 3 for temporary, 
permanent, R1 or R2, respectively. If the new 
mode is temporary, the track count will be 
adjusted. (Temporary files are not counted 
against the user's track quota.) 
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XX-CARRY: The file NAM El NAME 2 .will be carried to the 

other computer and will be loaded onto the 
d ‘ sk during the next load or update. It will 
be loaded as permanent mode, as the same name 
NAME 1 NAME 2, within the same 

pr ob 1 em-pr ogr ainmer file directory. If a 

different problem-programmer specification is 
desired for the receiving file directory OP 
may be PROS PRUG, i.e., the desired problem 
programmer numbers. If a different file name 
is desired, OP may be PROS PROG NAM1 NAM 2. 
where PROB PROG must be the problem programmer 
numbers for the receiving file directory and 
NAM1 NAM2 may be the name given to the input 
file. 

The file NAME1 NAME2 on this machine is in no 
way changed. Any previous versions of the 
file on the receiving machine will be deleted 
regardless of mode. 

XX=PRNOEL; DPUOEL; BPUDEL; 7PUUEL : 

The file(s) will be PRlNTed, DPUNCHed, 
dPUNCHed, or 7PUNCHed and then the mode will 
be changed to temporary. The next time the 
file is read or the user logs out, the file 
will be deleted. This is safer than a process 
request followed by a DELETE request. In case 
of machine or tape failure during the 
processing of the request, the operations 
staff will nave the opportunity of restarting 
tht disk edi tor. 


i-1 et hod 

The RQUEST command creates or appenJs to a file in the 
user s file directory called OUTPUT RQUEST. This file 
contains control card images which will be processed by the 
disk editor program. After processing, the disk editor 
program will change the mode of OUTPUT RQUEST to temporary. 

h ,s change to temporary allows the operations staff to 
rerun the disk editor if any difficulty was encountered in 
tie first run. Note that OUTPUT RQUEST contains only the 
control cards which point to the actual files to be 
processed. The disx editor program, upon processing the 
request files, will generate three different tapes: printer, 
punch, and carry. These tapes are then the responsibility 
of the operations staff. 
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iden tif icati o n 

Relocatable program loading 

LOAD/ LOADGO/ V LOAD/ NCLOAD/ L y USE 

P urpo se 

There are five different types of loading available for 
relocatable programs i.e./ SSS files. The first (LOAD) will 
load a program into core without destroying the loader or 
MOVIE) table, place the program in dormant status and 
return to the user for the next command. The second (LOADGO) 
is the result of the chain of commands LOAD and START. The 
third (VLOAD) will load the program; move all of the program 
and COMMON down in core to destroy the loader and MOVIE) 
table (thereby making the available core larger); place the 
program in dormant status and return to the user for the 
next command. The fourth (NCLOAD) is the same as VLOAD 
except that erasable COMMON is also destroyed so that no 
library routines which use erasable COMMON may be used. The 
fifth (L) is a separate command which allows any one of the 
previously mentioned four to be used with larger loading 
tables (see Restrictions). 

Programs or files may be loaded (or searched as library 
files) from the user's file directory, from his common files 
and from several system files. 

If needed routines cannot be found by the loader, the USE 
command may be used to specify which routines may be used 
i ns tead . 

Restrictions 

Normal table sizes are: MUVIE) table is 500 words and the 
table of missing entries is 100. 

The tables for the L command are: MUVIE) table of 1200 words 
and missing entries of 250 words. 

UiltiAe 

Any of the load commands (LUAD, LUADGO, VLUAD, NCLOAD) may 
be used in place of LOAD; all special arguments are optional 
and order is significant by meaning or where specified. 
Special arguments are those beginning and ending with 
parentheses as shown. They cause the loader to behave in a 
special manner. The non-special arguments are either file 
names or entry points, depending upon the preceding special 
ar gumen ts . 

Upon completion of loading, the current file directory is 
switched to its initial status. 
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LOAD (OLD) (ORG) (CFLn) ( LI BE) (SYS) (NEED) (NUB) NAMES (MORE) 

(OLD) The presence of (OLD) as the first argument 
instructs the loader to replace itself with 
the old loader and to use the old library 
version of 11 / 18 / 64 ). These old versions will 
be maintained in the system file for some 
short time for compatibility with old BSS 
files. 

(ORG) The presence of (ORG) instructs the loader to 
set the starting address to the entry name 
specified by the next non-special argument 
following (ORG). The non-special argument 
must be a primary file name. 

(NEED) The presence of (NEED) instructs the loader to 
treat the next non-special argument as a 
program entry point as though it had been an 
entry in a transfer vector. 

(MORE) may be the last argument before the carriage 

return (because only one line can be 

interpreted by the command) to indicate that 
more arguments will be specified. in this 
case the loader will not print the NEED list; 
wi 1 1 restore the common file switching to the 
initial setting; and return to the user (by 
way of CHNCOM) so that the USE command may be 
used. 

(CFLn) directs the loader to switch the current file 
directory to common file directory n which may 
be 0/ 1, 2/ 3, or 4. The current f i le 

directory is initially the user's file 

directory or a directory set by a CQMF I L 
command. There may be any number of these 
switches in the argument list and each one 
supercedes the previous one. 

(LIBE) directs the loader to use the next non-special 
argument as a file within the current file 
directory to be searched as a library file to 
find any missing routines. 

(SYS) directs the loader to use the following 
non-special argument as a f i le from the system 
file directory to be searched as a library for 
any missing routines. 

(NLIB) directs the loader not to search the system 
library (i.e., TSLIB1) for missing routines 
after the argument list has been processed. 
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(LIB) 

NAMES 

NEED 


USE 

LOAD 


LUADGU 

VLUAD 

NC LOAD 


supercedes (NLIB). 

may be the primary names of BSS files to be 
loaded or BSS f i les to be searched as 
libraries following certain special arguments 
or routine entry points following other 
special arguments. 

Following the processing of the argument list, 
the system library TSLIB1 will be searched for 
any missing routines (unless prohibited by 
(NLIB) ). If routines are still missing/ the 
current file directory is switched to the 
user's directory/ a list of needed routines 
(by entry names) is typed by the loader and 
DORM NT is called so that the user may type the 
USE command. Upon completion of loading/ the 
current file directory is switched to its 
initial status. 

will reinstate the last common file switching 
and go back to the loader. All of the 
arguments avai lable to the loader are 
therefore available to USE. 

sets the origin of the first program at 
(5200)8. The MOVIE) table and the loader are 
left inviolate below this origin. COMMON 
addresses are relocated with the same parity 
as on the assembly listing. FAP coded 
subprograms/ which contain the EVEN pseudo op, 
will be loaded with relative location 0 in an 
even core location. Upon completion/ all 
loaders call CHNCOM with an available core 
image specified. 

is equivalent to the sequence of commands LOAD 
and START. 

After the entire program and library 
subroutines have been LOAOed the program is 
moved down so that the origin is (30)8, 
covering the loader and the MOVIE) table. The 
( 31t> ) 8 words of erasable COMMON are included 
with the program. The MOVIE) table will be 
preserved if MO V I E ) occurs in the transfer 
vector of any routine loaded. 

is the same as VLOAD except that the (316)8 
words of erasable COMMON are not included and/ 
therefore/ if library subroutines which use 
erasable common are included, a COMMON 
assignment error message will be printed. 
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L The L command may be used if larger loading 

tables are needed (see Restrictions). The L ") 

precedes any one of the LOAD commands as: L 
LOAD ARGUMENTS. If the loader name is 

omitted, it is assumed to be LOAD. All of the 
regular loader arguments are available except 
(OLD). The program loading by LOAD starts as 
(7000)8 instead of (5200)8. There may be more 
than 250 missing entry names if this does not 
occur during a library search. L always calls 
CHNCOM, regardless of the outcome of the 
loading. No core image is kept if loading 
f ai led. 

MOVIE) table is created by the loader to provide a 
storage map of all entry points of routines as 
they are loaded. It is always written as a 
file (MOVIE TABLE) in the user's directory in 
temporary mode. If the entry MOVIE) appears in 
the transfer vector of any routine loaded, by 
VLOAD or NCLOAD, the MOVIE) table will be 
preserved by moving it to the top of the load. 

The MOVIE) entry points to location (27)8 
which. contains the MOVIE keyword which 
contains the number of words in the movie 
table in the decrement and the location of the 
lowest word in the movie table in the address. I# 

The format of the MO VIE) table, starting with 
the lowest location, is: 

1. fence 

2. Lowest common break (address) 

3. SVN prefix 

4. Memory bound (address) 

5. BCD entry name 

b. Entry point for previous name 
( add res s ) 

•• Pairs of words 5 and 6 for each 
entry to the subprogram. 

7. 8VN prefix or P2E U,,n, where there 
are n words in this program. 

8. Origin of this subprogram (address) 

.. Repeat groups 5 thru 8 for each 

subprogram loaded. 
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STORAGE MAP 


(LOCATION) 8 CONTENTS 



0-7 

10-23 

24 

25 

26 

27 

ZERO 

BOOTSTRAP for 
TSX ( ORG) / 4 

TSX ( ORG2 ) / 4 
TSX ( ORG3) / 4 
MOVIE) Keyword 

NCLOAD and 

VLOAD 

or TSX LOAD/ 4 

l 

30 1 

1 

1 

LOADER 1 

1 

VLOAD : 

1 

l 

i 

1 

NCLOAD: 1 

1 

1 

1 

l 

1 

FOR l 

1 

PROGRAM 

1 

1 

1 

PROGRAM 1 

1 

1 

1 

1 

LOAD/ 1 

1 

COMMON 

1 

1 

1 

1 

COMMON 1 

1 

1 

1 

i 

1 

LOADGO 1 

1 

TO 

1 

l 

1 

TO 1 

1 

1 

1 

I 

1 

1 

(77461)8 

1 

1 

1 

(77461)8 I 

_JL 

l 

1 

■ 

1 

1 

1 

ERASABLE 

l 

l 

1 

1 

1 

1 

1 

1 

1 

1 

1 

COMMON 

1 

1 

1 

1 

l 

1 

1 

1 

1 

1 

TO 

1 

1 

1 

1 

PROGRAM 1 

1 

1 

4661 1 

1 

1 

_| 

(77777)8 

1 

l 

i 

i 

i 

1 

i 

| 

1 

PROGRAM 1 

1 


_ 1 

1 

i 

MB 3 1 

1 

l 

COMMON 1 

1 

PROGRAM 

1 

1 


1 

l 

I 

l 

ERASABLE 1 

MB 2 

1 

1 


5200 1 

1 

COMMON l 

1 




1 

1 

1 

1 

PROGRAM 1 

i 




1 

1 

1 

MB 1 1 

1 




MB 3 = 30 

+ 77461 - COMMON 

BREAK + PROGRAM 

LENGTH 


MS 2 = 316 + MB 3 
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I den t i f i cat i on 

Absolute Program loading 
LDABS 

Purpose 

To load a program from a file containing absolute column 
binary card images. 


LDABS NAME1 

NAME1 is the primary name of the file NAM El ABS 
which contains absolute column binary card 
images with full word checksum. 

LBABS occupies the upper (1271)8 locations of core 
and it will load a program into lower core 
with an upper limit of (77503)8. The memory 
bound is set/ upon completion of the load/ to 
the highest location loaded. Loading 
terminates with a transfer card and execution 
may be started at the transfer-location by 
issuing the START command. 

Error Cond i ti ons : 

a) If a check sum error occurs, the comment: 
CHECK SUM ERROR IN CARD XXXXX is printed , 
where XXXXX is the location in which the first 
word on the card is to be stored. After this 
comment is printed the card is ignored and 
loading continues. 

b) If an attempt is made to store in a location 

greater than (77503)8, the comment: CARD 

YYYYY OVER BOUND is printed, the card ignored, 
and loading continued. 

c) If a transfer card is missing, i .e. , an end of 
file is reached, the comment: TRANSFER CARD 
MISSING, TYPE OCTAL STARTING LOCATION is 
printed. The last five characters typed are 
converted to an octal location and the 
transfer location for starting is set up. 
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Identification 

Start or continue execution 

START, RESTOR, RESUME, R, RSTART, CO NT i N, RECALL 
Purpose 

A program which has been LQADed may be STARTed or a program 
which has been SAVEd may be RESUMEd. In other words, 
programs may be stopped, saved, and subsequently restarted. 

Usase 

START 

RESTART 

The START command may be used to begin a program which has 
been loaded by one of the LOAD commands, or it may be used 
to continue a dormant program from the place of the last 
i nterruption. 

RSTART is equivalent to START, except that it is transparent 
to the current command buffer and command location counter. 
It should be used when restarting a chain of commands. 

RESTOR NAM El 
RECALL NAM El 

The RESTOR and RECALL commands will restore the core image 
from NAM El SAVED complete with active files, if any. The 
program is placed in dormant status so that it may be 
STARTed in order to continue from its last interruption. 

RECALL also restores the command list and common file 
switching from NAME1 SAVED, and sets aside the command 
location counter and current command buffer in case of a 
subsequent RESTART. 

RESUME NAM El PI P2 . . . Pn 

The word RESUME may be abbreviated by the letter R. The 
RESUME command is effectively the same as RESTOR and START. 
The parameters are placed in the current command buffer so 
that it contains NAME 1 PI P2 ... Pn. This is a technique 
for writing and checking out a new command. 

CO NT IN NAM El 

The CONTI N command should be used to resume a program 
involving a chain of commands. It restores the program and 
mach i ne co nd i t i ons f r om NAM El SAVED, together with any 
active files, the common file switching, and the contents of 
the command list, command location counter, and current 
command buffer. In other words, it is exactly equivalent to 
the chain of RECALL and RSTART. 
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I den t i f i cat i on 

General discussion of debugging commands. 

Method 

There are three different kinds of commands within CTSS, one 
of which is of no importance in this discussion. The first 
kind is often referred to as a "d i sc- 1 oaded" command. The 
distinctive property is that the supervisor loads the 
command from a core image SAVEd file and thereby eliminates 
any previous core image the user might have had. The second 
kind is often referred to as a "core-B transfer" command. 
Here the distinctive property is that the supervisor does 
not load the command, but instead, transfers to the 

relocating loader which is already in core-B. The loader 
then determines which command is specified and proceeds to 
load the command from a standard BSS library file (TSLIB2) 
into the area of core above the current core image. If the 
command has already been loaded, the loader merely transfers 
to the desired entry point. 

Some of the present debugging commands are core-B transfer 
commands. The earliest routine available to CTSS was 

called FLEXPM which includes the commands PM, PATCH, STOPAT, 
and TRA. More sophisticated commands have been written more 
recently, such as FAPDBG and STRACE. These routines are 
able to make use of the tables created by the translators 
and the loader, such as the MOVIE) table and symbol table 
files. The use of these commands imposes some restrictions 
on the user, namely that the vanishing and absolute loaders 
not be used and that the symbol table files from the 

translators be available and of the proper format. 

Programs which extend the memory bound during execution 
create some problems in connection with the debugging 
routines. Note that the core-B transfer commands are 

relocatable BSS subroutines with normal entry points. If 
the debugging routine is loaded after the program has 
started execution, there may be a conflict about the space 
acquired by expanding memory bound. Therefore, the solution 
is to force the debugging subroutines to be loaded with the 
program before execution. This may be accomplished either 
by placing one of the entry points in a transfer vector of 
one of the loaded programs or by use of the special 
arguments to the LOAD command. 

The SP command is a disc-loaded command which may be used 
only by the system programs for patching core-A. 

The SD command may generally be used for examination of 
locations in core-A. 

The MADBUG command is a disc loaded command which serves as 
an intermediate supervisor between the user and the CTSS 
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supervisor. MADBUG allows the user to specify a MAD source 
file rather than BSS file. MADBUG manages all the calls to 
the MAD translator and the appropriate loader so that the 
restrictions implied by the core-B transfer routines are not 
as evident to the user. 
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I denti f i cation 

FAPDBG - A symbolic debugging aid for FAP program 
R. H. Campbel 1 - x 

Purpose 

FAPDBG, as a symbolic debugging aid for FAP programs, was 
produced as an experiment with typing conventions and 
formats. FAPDBG acts upon requests typed by the user on the 
console and performs such functions as examining and typing 
or changing the contents of specified registers and allowing 
a subprogram to be run in controlled segments. 

Reference 

CC-216 FAPDBG, a symbolic debugging aid R. H. Campbell 
Usage 


LOAD NAM El ARGUMENTS 

FAPDBG ALPHA 
r eques ts 

The FAPDBG command can. be issued anytime a program is 
dormant and the loader is available, i.e., may not have been 
loaded by a self-erasing loader. If the program extends 
memory bound or damages the loader, FAPDBG should be called 
before execution. The FAPDBG command calls the loader to 
load the FAPDBG subprogram from the debug library, "TSLIB2". 
FAPDBG uses the loader's symbol and loading tables to build 
its own symbol table (800 symbols maximum) for the 
subprograms which the user wishes to debug. FAPDBG is 
approximately (12400)8 locations in length. 

If the line-numbered file ALPHA DEBUG can be found, requests 
are taken from there. When ALPHA DEBUG is exhausted, not 
found, or not specified, requests will be taken from the 
console. 

Convent i ons : 

1) A request is a single letter request name followed 
by arguments, all separated by blanks. 

2) A blank is a string of any number (not zero) of 
spaces or tabulations. 

3) Any number of requests may be concatenated on one 
line by typing an apostrophe or an equal sign 
between successive requests. Concatenation is 
recommended since FAPDBG will be brought into core 
less often and will generate less output. 

4) If a. request cannot be accomplished, FAPDBG will 

so inform the user and return to process the next 
reques t . 
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5) Syntax - The location / address, tag, and decrement 
parts of a request argument may consist of strings 
of symbols and octal numbers separated by plus and 
minus signs to denote the desired algebraic 
manipulation. The indicated operations are carried 
out, any negative result is converted to two's 
complement form and the right fifteen bits saved 
(in the case of the tag field, only the right 
three bits are saved). Symbols, which must be 
defined, may consist of any number of characters, 
at least one of which must be non-nurneric (i.e., 
not 0 through 7), and none of which may be one of 
the special characters plus, minus , comma, space, 
or tabulate. If the number of characters is 
greater than six, only the last six will be used. 
Any string consisting only of the digits 0 through 
7 will be considered an octal number of five 
digits, with left zeros if necessary. If more than 
five digits are typed, only the last five will be 
used. The line typed in is scanned from the left 
and each field is evaluated when encountered. If 
an undefined symbol is discovered, or a deviation 
from an understandable format is discovered, an 
appropriate comment is typed and processing of the 
request is terminated. If one or more requests 
cannot be interpreted, any .go or .proceed requests 
foil ow i ng t hem on the same line will be ignored. 
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There are four classes of requests: set up, register 
examination and modification, subprogram control, and FAPDBG 
contro 1 . 


S£I REQUESTS : 

The set up requests are necessary to tell FAPDBG which 
subprograms are to be debugged and allow FAPDBG to build the 
necessary symbol tables. These requests are .Load address, 
symbol Jable, Mork, and Equals. 

LOAD ADDRESS: L ENTRY 


ENTRY is an entry point of the subprogram to be 
debugged. The origin of the subprogram will be 
typed out and will be used as the relocation 
constant for all symbols within that 
subprogram. 


SYMBOL TABLE: T -NAME1- 

All the symbols from the file NAM El SYMTB will 
be relocated by the origin printed from the 
last L request and placed in the FAPDBG symbol 
table. Note that this means absolute symbols 
and COMMON (except for the f i rs t- 1 oaded) will 
be incorrect. 

Successful completion is signaled by "SYMBOLS 
LOADED", if the FAPDBG symbol table becomes 
full, the last symbol entered will be typed 
out. Note that the symbols in the SYMTB file 
are in alphebetic order. 

If NAM El is omitted, all of tie symbols will 
be deleted from the FAPDBG symbol table. 

WORK: W ENTRY -NAME1- 

W is the combination of L and T requests. 

NAM El need not be specified if ENTRY and NAME1 are 
the same. 

EQUALS: E FE FS 

FS is the symbol to be entered in the symbol 
table with the value of the expression FE. 

FE is a FAP expression involving constants and/or 

symbols already entered in the symbol table 
(see convention 6.) 
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R£fii § ter, Exami nation and Mod i f i cat ion 


The r eg i ster exam ination and mod ification requests permit 
the user to examine and change the contents of core 
locations as. well as the live registers. They are look 
(floating point/ Hollerith/ full word integer/ decrement 
integer/ octal/ symbolic)/ deposit/ compare/ signed and 
logical accumulator/ and storage map. 

LOOK: -request- -LOCI- -L0C2- 

request sets the output conversion mode and if an 
argument is specified/ prints the specified 
locations. Request may be one of the 
fol lowi ng: 


F Floating point 
H Hollerith 
I Full word integer 
J Decrement integer (Fortran) 

0 Octal 
S Symbo 1 i c 

LOCI L0C2 are FAP symbolic expressions specifying a 
block of core from LOCI through L0C2. 

LOCI specifies a single location. 


The contents of a single location in the 
current output mode may be obtained by typing 
just the location expression without the look 
request with the restriction that the first 
symbol in the expression may not be a single 
letter. The contents of "* + 1" may be 
obtained by an empty request (just a carriage 
return or concatenation character). 

DEPOSIT: D LOC FW 

FW is the FAP word to replace the previous 
contents of location LUC. 


This request may be abbreviated by omitting 
the request name, provided that the location 
expression does not begin with a s i ngl e- 1 etter 
symbol. The FAP word may be a symbolic machine 
instruction such as CAL ALPHA-10/4 or one of 
the data generating pseudo instructions OCT/ 
BCD/ FLU, I NT (full word decimal integer)/ or 
JNT (decrement integer) followed by a blank 
and one word of data. 
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I 


f 




i 



COMPARE 


A symbolic machine instruction consists of. a 
symbolic operation code/ an optional asterisk 
to indicate indirect addressing/ and an 
optional variable field in the same format as 
accepted by FAP/ except that all numbers are 
interpreted as octal and that multiplication 
and division are not allowed. No blank may 
intervene between the operation code and t e 
indirect flag; a blank must/ however/ precede 
the variable field. Note that since the 

address field is truncated to fifteen bits/ 
the left three bits of the address. part 
type D instructions (left and right bait 
indicator operations) will be considered by 
FAPDBG as the tag field/ both for input and 
for output. Thus to insert the instruction 

RFT 300105 

it is necessary to type 

RFT 105/3 

The OCT pseudo instruction accepts a signed or 
unsigned octal integer of magnitude less than 
or equal to 377777777777. Thus/ to 
traditional fence/ it is necessary 

OCT -377777777777 


insert 
to type 


the 


The FLO pseudo instruction accepts a signed or 
unsigned floating point number with optional 
decimal point and optional E modifier to 
denote multiplication by the indicated power 
of ten. The B modifier is not allowed. 

The I NT and JNT pseudo instructions accept 
sinned or unsigned decimal integers or 
sufficiently small magnitude to fit into the 
number of bits available (34359738367 for l NT 
and 131071 for JNT) . 

The BCD pseudo instruction accepts any string 
of characters preceding the request terminator 
and assembles the last six into one word. If 
fewer than six characters are typed/ spaces 
will be inserted on the left. Note that this 
pseudo instruction uses the input line image 
after FAPDBG has edited and normalized it. 
Therefore a string of spaces and tabulations 
will be interpreted as a single blank. 


and VERIFY: 


C ENTRY -NAR1E1- 
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ENTRY is the entry point of a subprogram already 
1 oaded in core. 

NAM El BSS is the name of the file which is to be 
compared with the core image of ENTRY. NAME1 
need not be specified if it is the same as 
ENTRY. 


C by using the origin value of the ENTRY 
subprogram, it will read and relocate each 
word in NAME1 BSS and compare it with the 
corresponding word in core. If a discrepency 
is found, FAPDBG will type in the current mode 
the location, the word from NAM El, and the 
contents of the memory location for which 
there is a discrepancy. "EXAMINATION 

CONCLUDED" will signal the completion of the 
request. The request may be terminated by a 
single interrupt; FAPDBG will close the BSS 
file and return to process the next request. 

ACCUMULATOR: A -FW- or K -FW- 


A places the FAP word 'FW' in the signed 
accumulator and clears the P and Q bits. 

K places the FAP word 'FW in the logical 
accumulator and clears the sign and Q bits. 

A (or K) without argument types out, in the current 
mode, the contents of the signed (logical) 
accumulator followed by the P and Q (sign and 
Q) bits. 

STORAGE MAP: M 

M requests the typing of the storage map with 
subprograms listed in order of loading. The 
map includes the origin and entry points with 
thei r locat i ons. 


Subprogram Control 


The requests which have to do with subprogram control allow 
the user to run his subprogram in controlled segments. They 
are J 2 .reak, .go, and proceed. 

BREAK: B -LOC- 

Conditions FAPDBG to insert a "breakpoint" at 
location LGC. FAPDBG will save the location 
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and set an indicator to signal that a 
breakpoint instruction/ specifically a 
transfer into FAPDB.G/ is to be inserted into 
that location. No subprogram modification 
occurs at this time. An examination of the 
breakpoint location will reveal its original 
contents and changing the contents ( via a 
deposit request) will not remove the 
breakpoint. The breakpoint must not be placed 
at a subprogram-modified instruction or where 
it would be used for indirect addressing. 
Only one breakpoint at a time may be inserted. 

The omission of LOC in the request causes the 
breakpoint to be removed. 

GO: G LOC 

Allows the user to start execution of the 
subprogram at location/ LOC. FAPDBG will 
examine the breakpoint flag and/ if a 
breakpoint exists, will save the contents of 
the break location and insert the necessary 
transfer instruction. It will then restore the 
machine conditions, and transfer to the 
specified location. 


PROCEED: P 

Allows the user to continue executing his 
subprogram from the state it was in just 
before control last entered FAPDBG. Upon 
encountering the breakpoint transfer 

instruction, control will be transferred to 
FAPDBG, which will save the machine conditions 
and restore the temporar i 1 y- removed 

instruction at the break location. FAPDBG will 
then type "BREAK." and wait for requests. 

JProceed will cause FAPDBG to perforin all the 
steps performed by .go, except that after 
restoring the machine conditions, FAPDBG will 
execute the above-mentioned instruction and 
transfer to the appropriate location following 
its location as governed by any skipping which 
might occur. If the instruction is 

location-dependent, namely TSX, STR, STL, or 
XEC, FAPDBG will interpret it as if it were 
being executed from its normal location. Thus 
a breakpoint may be inserted at a subroutine 
call. A chain of XEC instructions will be 
interpreted to a maximum depth of ten. A 
subprogram in operation may be interrupted at 
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any time by pressing the interrupt button. 


Internal Oper at i on 


The request which controls 
user to return to CTSS. It 


the internal operation allows the 
•s suit. 


QUIT: 


Returns control to the 
i n such a way that 
transfer control to the 
subprogram where i t 
status. 


Time Sharing Supervisor 
a START command will 
place in the user's 
last entered dormant 
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I nter na 1 Symbol s 


The following symbols are permanently defined in FAPDBG as 
locations where the machine conditions are stored. 

$MQ The multiplier-quotient register. 

$A The signed accumulator 

$K The logical accumulator 

$SI The sense indicator register. 

$ X 1 Index register one. 

$X2 Index register two. 

SX3 Index register three. 

SX4 Index register four. 

$X5 Index register five. 

$ Xb Index register six. 

$X7 Index register seven. 

* The current location. 

This symbol is defined as the last location 
referred to by either the user or FAPDBG. It 
is redefined as the location of the next 
instruction to be executed in the user's 
subprogram by encountering a breakpoint or by 
a manual restart. 

$ LS Lights and switches. 

This location contains the state of the 
machine conditions in the right*most eight 
octal digits as listed below; the off status 
is represented by zero, on status by one. 
Reading from left to right: 

digit condition 

5 Floating point trap mode, 

b Divide check 1 i ght . 

7 0 ver f 1 ow 1 i gh t . 

8 multiple tagging light. 

9 dense 1 i ght one. 

10 dense light two. 

11 dense light three. 

12 dense light f our . 


$IC The instruction location counter. 

This location contains the address of the next 
instruction to be executed in the user's 
subprogram. It is set by encountering a 
breakpoint or by a manual restart. It is 
examined by the proceed request in order to 
determine the location to which to transfer 
contro 1 . 
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JjlM Ufi &t 
FN 
LUC 
EP FN 
EP 

LUC FW 
FE FS 

LUC 

LUC 1 LUC2 
LUC 

LUC 

LUC1 LUC2 
LUC 

LUC 1 LUC2 
LUC 

LUC1 LUC2 
F W 

EP 


LUC 

LUC1 LUC2 


LUC 

LUC 1 LUC2 
T FN 

T 

W E P F N 
W EP 
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Smorngry Requests j_n A1 phabet i c Urder 


Meani ng 


CLA -FW 

Type out signed AC with P and Q 
Insert breakpoint at LUC 
Remove breakpoint 

Compare and type discrepancies of subprogram 
EP and FN tJSS. 

C EP EP i.e., EP and FN are identical. 

Depos i t =FW i n LUC 

Define symbol FS equal to expression FE 
Set output mode to floating point 
Set floating point and type C(LUC) 

Set floating point and type C(L0C1 thru LUC2 ) 

Go to LUC 

Set output mode to Hollerith 
Set Hollerith and type C(LUC) 

Set Hollerith and type C(LUC1 thru LUC2 ) 

Set output mode to decimal integer 
Set integer and type CCLUC) 

Set integer and type C(LUC1 thru LUC2 ) 

Set output mode to decrement integer 
Set decrement integer and type CCLUC) 

Set decrement integer and type CCLUC1 thru LUC2) 
CAL -FW 

Type logical AC with S and Q. 

Find and type origin of subprogram EP 

Type storage map 

Set output mode to octal 

Set octal and type CCLUC) 

Set octal and type CCLUC1 thru LUC2) 

Proceed (location in $IC) or interrupt 
after break 

Quit and return to CTSS 
Set output to symbolic 
Set symbolic and type CCLUC) 

Set symbolic and type CCL0C1 thru L0C2) 

Add symbols from FN SYRITd to symbol table 
(relocated by last origin typed out) 

Remove all symbols from symbol table 
L EP' T FN; work subprogram EP with 
symbols from FN SYmTd 
L EP' T EP: FN is identical to EP 
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I dent i f i cat ion 

MADBUG - A MAD Debugging System 
Robert S. Fabry 


Pu rpose 


MADBUG is a system under which the user can create and debug 
programs written in the MAD programming language. MADBUG 
allows the user to input and edit symbolic programs and to 
execute in a controlled way and interrogate the. derived 
machine language programs. The most important consideration 
in the design of MADBUG was ease in learning and using, both 
for the beginner and for the advanced programmer. MADBUG is 
unusual in that it utilizes information which has been 
previously ignored. This information comes from. (1) the 
sequence in which the user types his requests, (2) the files 
available in the user's file directory, (3) the expanded 
information content of the new MAD symbol table f i es 
developed for MADBUG, and (4) the information inherent in 
the very limited, stylized set of coding sequences generated 
by a compiler. The use of this additional information 
manifests itself in two ways: (1) the user need Provide very 
little information to accomplish a given task, and (2) the 
user does not have to understand assembly languages, 
machine languages, octal numbers, relative or absolute 
addresses, symbol tables, machine representations of 
constants, or any of a host of similar items. The MADBUG 
requests of CHANGE, DELETE, INSERT, and APPEND demonstrate 
the influence of the "Expensive Typewriter" program, written 
for the PDP-1 by Steve Piner. The "DDT" program written for 
the PDP-1 by Robert Saunders and the "FLIT" program written 
for the TX-0 by Jack Dennis and Thomas Stockham have 
influenced the OPEN, VERIFY, BREAK, and KILL requests. 


Refe rence 

CC-247 and Mac-M-205 MADBUG: A MAD DEBUGGING SYSTEM R.S. 
Fabry 
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A DESCR I PTI ON OF MADBUG 

MADBUG. is instructed by requests, typed one per line. A 
request line is made up of the name of the request followed 
by its arguments, with one or more blanks for separation. 
Request names may be abbreviated by their first letter. In 
request lines, tabulation characters are equivalent to 
blanks. There may be blanks before the request name and 
after the last argument; blank request lines are ignored. 
Since blanks are used as delimiters, the arguments, which 
may be as complicated as "a( 1)+1. . . b-3", must be typed 
without internal blanks. A request which operates on 
variables will operate on single variables or on blocks of 
variables, specified in the usual MAD manner as 
"al pha . . . beta" ; a request which operates on cards will 
operate on single cards or on blocks of cards. For example, 
"verify alpha beta( 1) . . .beta( 3 ) k(l,l,l)" would verify, in a 
sense described later, the variables ALPHA, BETA(l), 
BETA( 2 ) , BETAC3), and K(l,l,l). 

MADBUG requests can be classified into four groups; the edit 
requests which are PRINT, DELETE, INSERT, CHANGE, APPEND, 
MANIPULATE, and TRANSLATE; the core requests which are GO, 
OPEN, VERIFY, LINKAGE, BREAK, KILL, SAVE, and RESTORE; the 
requests for returning to CTSS which are QUIT and EXECUTE; 
and the declarations which are WORK, USE, and FORCE. These 
requests will be discussed in the next few sections. 

The Work Request: 

The MADBUG requests are carried out in the context of a 
single MAD subprogram. The WORK request allows the user to 
declare which subprogram is of interest. For example: "work 
prog" sets up MADBUG to work on the program in file PROG 
MAD. The file PROG MAD does not have to exist. As 
illustrated in the sample session, if the user adds lines to 
a non-existant file, MADBUG will create the file. Thus, if 
the user is working in the context of a subprogram PROG, and 
wishes to print a subprogram ROOT, he must first request 
"work root" and then may request "print". 

Edit Re quests: 

MADBUG uses a different technique for editing than the CTSS 
EDIT command. Neither the user nor MADBUG supplies a line 
number for a card image. Instead of indicating a card image 
by giving its associated line number, the user has three 
options: (1) the statement label on the card, if any; (2) 
the card's position relative to another card which has a 
statement label (the third card before ALPHA is ALPHA-3; and 
(3) the number of the card in the deck (the 17th card in the 
deck is simply 17). In counting for (2) or (3), the user 
must count all physical card images including remark and 
continuation cards. MADBUG interprets the arguments of a 
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request before executing the request; thus, i f a 
consisted of three cards, "delete 1 2" would leave the third 
card, but "delete 1" followed on another line by delete 2 
would leave the second card. 

In unusual situations there may be a long section of program 
with no statement labels. The user is free to insert remark 
cards with statement labels in such a case. MADBUG, but not 
the MAD translator, will allow references to statement 
labels on remark cards. 


Three special conventions exist for specifying statement 
labels- (1) the is always taken to mean the previous 

card referred to by the user, so that a "print *+3" after a 
"print 6" would print the 9th card, and so that a print 
alpha. ..*+2" would print three cards starting with ALPHA. 
(2) the "/" is always taken to mean the last card i n ^ the 
deck, so that, in a five card program, "print 135 
identical to "print 1 3 /". (3) Requests which operate on 
cards will operate on every card in the subprogram if no 
cards are specified, so that "print" is identical to print 

1 .../". 

MADBUG observes the standard conventions of horizontal 
spacing: the characters after a tab will be moved to column 
12 and the characters after a tab-backspace will be moved to 
column 11. 

The description of several of the editing requests will 
refer to input line blocks. An input line block consists of 
all the lines the user types before typing a blank line. 
The editing requests are defined as follows: 


PRINT will print all cards mentioned as arguments. 

Thus, "print a( 1) + 1. . .b-3" would print a block 
of cards starting with the card after the card 
labeled A(l) and ending with the third card 
before the card labeled B. 

DELETE will delete all cards mentioned as arguments. 

Thus, "delete" would delete all of the cards 
of the subprogram being worked, and "delete 1 
3. ..6" would delete the first and the third 
through sixth cards. 

INSERT will insert successive input line blocks 
before successive cards mentioned as 

arguments. Thus, one might see the following 
sequence : 

U : p r i nt 
M : ONE 
M : 

U : i nser t 
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U : ze ro 
U: 

U:pr i nt 
M: ZERO 
M : ONE 
M: 

U: i nsert 1 one 
U : a 
U: 

U : b 
U: 

U : pr i nt 
M: A 

M : ZERO 
M: B 
M : ONE 
M: 

CHANGE will replace successive cards or blocks of 
cards, given as arguments, by successive input 
1 i ne blocks. A block containing any number of 
cards may be replaced by an input line block 
of any length. 

APPEND with no arguments will append the input line 
block which follows the request line to the 
subprogram being worked. On the other hand, 
if the request has arguments, they are taken 
to refer to. MAD subprograms which will be 
appended, in order, to the program being 
worked. 

APPEND is also useful for creating a modified 
version of a subprogram while keeping the 
original. To do this, WORK the new name, 
APPEND the old name, and then make 
mod i f i cat i ons . 

MANIPULATE is a request for character manipulation within 
a card image.. The first argument specifies 
the manipulation. Arguments after t-he first 
specify cards within which the manipulation 
will be performed. The first argument has the 
form: /***/***/ where the slash stands for any 
separation or delimiter character which must 
occur . exact 1 y three times, and the strings of 
asterisks stand for any pa i r of character 
strings. The manipulation consists of 

replacing all occurances of the first string 
by the second string. Any character except a 
tab or space may be used as the delimiter; it 
is recognized by its being the first character 
of the. a rgument . The two character strings 
may include any characters except the 
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delimiter and the carriage return, and they 
may be of different lengths. If the first 
string is empty, it will be taken to match a 
null string before column one on the card, 
thus allowing a simple way of inserting a 
statement label on a card. As a confi rmation 
to the user, MADBUG will print a list of cards 
on which the manipulation is performed. If 

the manipulation is performed more than once 
on a card, the card will be included in the 
list once for each time the manipulation 
occurs. MADBUG does not consider replacing a 
string by itself to change the symbolic 
program. Thus the user can replace a string 
by itself to locate all occurences of the 
string. 

TRANSLATE has no arguments, and causes the subprogram 
being worked to be translated into machine 
language by the MAD compiler. From the user's 
point of view MADBUG is performing the 
translation. It is not necessary to translate 
any subprogram before using it. MADBUG will 
request any translations that are needed at 
load time. The TRANSLATE request is a 
convenience to the user who is changing 
several subprograms at one time, and who would 
like to catch any syntactic errors in one 
before turning his thoughts to another. 

The Use Request: 

The core requests, which will be discussed in the next 
section, operate in the context of a core image. MADBUG 
must have some way of knowing what subprograms to load when 
creating a core image. The arguments of the USE request are 
the subprograms to be used. Thus a user writing a 
subroutine ROOT and a test program MAIN might "use main 
root". There are provisions for using FAP programs, special 
libraries, and special loader parameters; these provisions 
are described later. 

Core Image Requests: 

Some core requests require cards for arguments, and their 
arguments observe the same conventions as those of the edit 
requests. A core request which refers to a declaration or 
remark card will operate on the first executable statement 
following the referenced card. Other core requests require 
variables for arguments. A variable is given as an argument 
in standard MAD notation, including mul t i -dimens i onal arrays 
and COMMON and ERASABLE variables, but not the dummy 
arguments of functions. Three special conventions exist 
for variables: (1) the "*" is always taken to mean the 
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previous variable, refered to by the user; (2) if no 
vari ables . are specified / the request will operate on every 
variable in the program; and (3) the block notation can be 
used to include several arrays or variables at once. 
Variables. are taken to be ordered alphabetically (with a 
blank coming after R, alas.) and then by linear subscript. 

The first time the user gives a core request, a core image 

tr^Li ?• creat ® d , b * MADBUG. This is accomplished by 
translating each of the needed subprograms into machine 
language ( f necessary, loading the subprograms into core, 
and finally modifying some of the subprograms in order to 
intercept. i 1 legal references to an array. If an error is 
detected in this process, the core image will not be formed, 
and the core request will be terminated. The user should 
correct. the error and try the core request again. The core 
image will be destroyed when the user issues the quit 
request or edits a program occuring in the core image. The 
core requests are defined as follows: 


GO will start the user program. A single card 
given as an argument for GO will cause the 
user program to.be started at the named card. 
If no argument is given, the user program will 
be started wherever it stopped last. A fresh 
core image will start at the beginning of the 
main program. 


The user program will remain in control until 
(1) it terminates by calling DEAD, DORMNT, 
ENDJOB, ERROR, or EXIT; (EXIT can be 

implicitly called by letting control reach an 
END OF PROGRAM or END OF FUNCTION card.) (2) 
a "breakpoint" is encountered by the user 
program; (3) the user interrupts by pushing 
the break button once; or (4) an array is 
referenced. wi th subscripts pointing outside of 
the dimensioned array. (Some array 
violations are not caught; this is 
in a later section.) On any 
occasions, control returns to MADBUG, and 
user is informed of the reason. 


d imens i on 
d i scussed 
of these 
the 


Infrequently, the user program may have an 
error. which causes control to return to CTSS. 
In this case, the user should type two CTSS 
commands, f i rst "save (user)" to save his own 
core image and second "resume (mdbg)" to 
return control to the core image on which 
MADBUG saved itself. Even if the first of 
these commands results in an error comment 
from CTSS, the user should type the second 
This procedure is called a manual restart? 
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OPEN will print the contents of variables mentioned 
as arguments, one by one, and after each, wait 
for the user to type a new value for the 
variable. If the user wishes the old value to 
remain, he just types a carriage return. In 

typing out the value of a variable, MADBUG 
makes use of the declared mode of the variable 
and of the current value to decide whether the 
value should be presented to the user in 
integer, alphabetic, floating-point. Boolean, 
statement label, or function mode. The user 
must type a constant for the new values in a 
form compatible with the declared mode of the 
variable. It is possible to change the 
input/ output form associated with 
mode permanently or to override 
associations for a single request, 
d i scussed later . 


a declared 
the normal 
This is 


One special note: because of the way the MAD 
compiler works, one may change the effect of a 
transfer statement by changing the value the 
variable which has the same name as the 
statement label to which the statement 
transfers. One may not, however, change the 
scope of a THROUGH loop in this fashion, even 
by changing the value of the variable with the 
same name as the THROUGH scope. 


VERIFY will cause the values of variables mentioned 
as arguments to be compared with the values of 
the same variables in a fresh, unexecuted 
version of core. Each variable whose value 
has changed will be printed with its present 
value. Its value in the fresh version of core 
will also be printed if it is non-zero. 

An option is available with verify; the user 
may specify any core image saved with the SAVE 
request to be used instead of the fresh copy 
of core discussed above. This is done .by 
giving the name of the saved image following 
the request name and before the list of 
variables to be varified. As the user will 
discover below, this name must begin with an 
asterisk, and can thus be recognized by 
MADBUG. 

The discussion of output forms used for the 
values of variables, which was given under the 
OPEN request, also holds for the VERIFY 
reques t . 
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LINKAGE causes MADBUG to tel 1 the user which statement 
made the most recent call to the external 
function subprogram currently being worked. 

BREAK will modify the machine language program in 
the current user core image so that control 
will return to MADBUG if one of the cards 
given as arguments is to be executed. When 
MADBUG regains control from the user program, 
the name of the statement which is about to be 
executed will be printed for the user. At 
this time the user will usually examine 
variables in his program to determine what his 
program is doing. "Breakpoints", as these 
points in the user core are called, belong to 
a given core image, and can vary from one 
saved core Image to another. (See the SAVE 

request . ) 

KILL will remove any breakpoints at cards mentioned 
as arguments. It is not an error to insert a 
breakpoint where one already exists nor to 
remove one which does not exist. For example, 
to kill all the breakpoints in the subprogram 
being worked, "kill". 

SAVE has a single name as its argument and causes a 
copy of the current user core image to be 
saved as a CTSS file with the primary name 
given as an argument and the secondary name 
SAVED. The name given by the user must begin 
with an asterisk. The current user core image 
was produced by loading, and has been modified 
by execution and by MADBUG requests. One may 
save the current core image under a name which 
has already been used for a save request. In 
this case, the current core image will replace 
the previous core image. All the core images 
saved using the SAVE request will be destroyed 
when the user's current core image is 
destroyed. This is because the saved files 
created by MADBUG are not normal CTSS saved 
files, and are useless out of the context of 
MADBUG. 

RESTORE will replace the current user core image with 
a copy of the image whose name is given as an 
argument. The core image name must be a name 
under which the user has saved a core image 
using the SAVE request, or it must be *FRESH. 
*FRESH is a byproduct of the loading process. 
It is a completely unexecuted version of core 
with no breakpoints and with all variables at 
their initial values. Except for the special 
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way in which it is created/ *FRESH is 1 ike any 
normal core image saved by the SAVE request. 


Getting Back to CTSS: 

When the user is finished with MADBUG/ and desires to return 
to CTSS/ he should use the QUIT request. The QUIT request 
will destroy all the files created during the session/ 
except for the modified MAD programs and their associated 
BSS and SYMTAB files. 


The EXECUTE request allows the user to return £TSS for a 
single command/ without ending his session with MADBUG. For 
example, the user could effect the CTSS command listf aa 
mad" by requesting "execute listf aa mad". These comman s 
are executed using the command chaining technique with the 
sequence: "save (mdbg)", the user's command, and resume 
(mdbg)". No provision is made for saving a core image which 
might result from the user's command. 
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SPECIALIZED FEATURES AND TECHNIQUES 

Two error comments that the user may get from MADBUG have 
special significance. One Is "TRY AGAIN. ", which always 
means that the current request has been terminated. The 
other is "CONSULT LISTINGS." which can only occur as a 
result of a bug in MADBUG. Any user getting this comment 
will please retain as much information in the way of output, 
files, etc. as he can and call Bob Fabry, x2524, so the bug 
can be removed promptly. The user can often continue with 
more requests in spite of a "CONSULT LISTINGS." error. 

Two types of improper array references are not caught. 
First, references with a constant linear subscript are not 
checked. For example, one might DIMENSION A(10) and 
A( 20 ) =100 . Second, references to arrays which are given as 
arguments to functions are not checked. For example, one 
could have called for ROOT.(AOO) where K is 20. This 
situation can sometimes be avoided by placing arrays in 
COMMON, and not passing them back and forth as arguments. 

In unusual cases, the user core image may "blow-up" in such 
a way that the information about control and about the 
values of variables is gone or meaningless. In this case 
the user will still find MADBUG a useful tool, and may 
approach the problem by an exponential search through time 
for the point at which the blow-up occurs. Stated another 
way, this amounts to performing a series of tests in which 
each test is designed to cut by a half the uncertainty about 
when the blow-up occurs. When the user knows the exact 
point of the blow-up, he can then step through very 
cautiously, looking for clues. Such an approach relies 
heavily on BREAK, KILL, SAVE and RESTORE. At the start, the 
user moves a core image as close to the blow-up as he knows 
he can, SAVEs the core image, and guesses the half-way mark, 
in terms of opportunities for bugs, to a place by which the 
blow-up must have occured. He then uses BREAK and KILL to 
step his current core image to the half-way point he 
guessed. (1) If the core image blows-up in this process, he 
guesses a new half-way point, half way between his saved 
image and his old half-way mark, RESTORES his saved core 
image, and trys his new guess. (2) If the core image 
doesn't blow-up in the process, he SAVEs his current core 
image for a new starting point, guesses a new half-way mark 
between his new core image and the blow-up, and trys this 
new guess. This process is fairly simple to carry out using 
MADBUG, and most blow-ups can be readily solved this way. 

When loading is performed, MADBUG will normally load a 
program named (MDBG ) , which MADBUG provides, immediately 
following the files specified by the USE request. Then 
MADBUG will process the core images of all programs loaded 
into core before (MDBG) and insert patches, using an area 
reserved in (MDBG), to attempt to catch any user subprogram 
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when it accesses an array with an illegal subscript. If the 
user wishes to load programs which were written in FAP, MAD 
programs for which the symbolic programs are not available, 
debugged MAD programs which he does not wish to protect, or 
library files, he may specify the position of (MDBG) by 
typing (MDBG) in place of a file name in the USE request. 
All the files before this parameter will be treated 
normally, and all things after it will be ignored by MADBUG 
and just passed on to the loader. Any loader parameters, 
such as (CFLP) or (LIBE), can also be used after (MDBG). If 
the user needs more than eighty characters for his USE 
request, he may type a hypen as an argument of use. When 
the hyphen is encountered, MADBUG will immediately read the 
next input line for more arguments for the USE request. 

This may be done for several successive lines. 

The FORCE request forces certain internal registers in 

MADBUG to new values, picked by the user. To FORCE a 

parameter, give the name of the parameter as the first 

argument of FORCE, and give remaining arguments as required 
by the parameter being forced: 

FORCE PATCH will set the amount of patch space 

available in the user core images to the 
decimal number given as the argument. 
Initially PATCH is set to 500. The patch 

space is used during loading and whenever 

breakpoints are inserted. FORCE PATCH does 
not change the available patch space 
immediately, since the internal register is 
examined only during loading. A user would 
reduce the patch space if he was squeezed for 
core space. He would increase it if MADBUG 

complains, during loading, that there is not 
enough patch space, or if he exhausted the 
patch space inserting breakpoints. If the 
patch space is exhausted by breakpoints, 
however, it is usually sufficient to KILL some 
of the less neccessary breakpoints to get 
space for new ones. 

FORCE FORMAT will set the normal input/output form 
associated with each of the possible modes for 
variables. After the word FORMAT, the 

arguments are taken in pairs, the first item 
of the pair indicates a mode and the second 
indicates a form. The modes are Indicated by 
a digit from 0 to 7, standing for 

floating-point, integer. Boolean, function, 
statement label, mode 5, mode 6, and mode 7, 
in that order. The form designation is one of 
the following: "Gn" for floating point with n 
significant figures on output, "I" for 
integer, "A" for alphabetic, "P" for either 
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integer or alphabetic with MADBUG picking for 
output, "0" for octal, "B" for Boolean, "S" 
for statement label, and "F" for function. 
Initially, FORMAT is set to: 0 G3 1 P 2 B 3 F 
4S506070. (In this section, "0" is 
used to denote the letter "0".) 

FORCE MODE alows the user to predetermine whether 
MADBUG saves itself as a permanant mode file 
or as a temporary mode file. The values of 
MODE are, correspondingly, "P" and "T". Mode 
is originally set to "P". The user will want 
to FORCE MODE to temporary if he is not 
interested in extreme reliability as much as 
in conserving his track allotment. 

It is also possible to override all the normal I/O forms for 
the duration of one OPEN or VERIFY request. To do this, use 
one of the form designations listed above, but preceded by a 
slash. Insert it after VERIFY (and the saved file name, if 
present) or OPEN and before the arguments. For example, 
"open /o alpha". 

MADBUG observes the convention that the first statement of a 
main program starts after the call to .SETUP which the 

compiler always inserts as the first executable machine 
instruction. Another convention at this level is imposed by 
the compiler. A breakpoint on an ENTRY TO statement will 
not be encountered when the entry is called, but will be 

encountered if control is transfered to the statement or 
falls to the statement. 

MADBUG creates and destroys special files as it processes 
the user's requests. They are destroyed during the 

processing of the same request for which they are created. 
Normally, the user will not have to worry about them, but 
occasionally he may be made aware of their existance. 
(MDBG) SAVED is the name under which MADBUG saves itself 
when it chains to other commands. This file will vary in 
length during a session, but will be on the order of 30 

tracks long. Its mode depends on the value of MODE, as 

described earlier. (TEMP) (MDBG) is used during file 

modification. When a word in a file must be modified, the 

modified file is first created as (TEMP) (MDBG), and then 
, the original file is deleted and (TEMP) (MDBG) is renamed. 
The length of this file depends on the length of the file 
being modified. The file has permanent mode. (MDBG) BSS is 
created by MADBUG whenever loading is required. Its 
position in the new core image was discussed earlier. It 
contains the bootstrap for MADBUG and the patch area. It is 
one track long and has temporary mode. (MBGI) SAVED is a 
very short program which processes the input line blocks the 
user types while editing. It processes all the input line 
blocks associated with one edit request and reads in the 
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following request before chaining back to MADBUG. It is 

usually one track long and is permanent mode. 

A user core image may use the command buffers. A call to 
CHNCOM will not return control to MADBUG. MADBUG saves the 
command buffers and counter initially and restores them when 
the user gives the QUIT request. MADBUG also treats the 
command buffers and counter as psuedO"mach i ne conditions 
associated with each core image. The buffers are only lost 
on manual restart. A fresh core image has empty buffers. 

By editing, the user modifies the MAD subprogram on which he 
is working. By inserting and removing breakpoints and by 
changing the values of variables, the user modifies the 
current user core image, (USER) SAVED. MADBUG does not 
change external files until the changes are logically 
needed. If the user uses EXECUTE to ask CTSS to process 
these files, he may want to insure that these logical 
modifications are made physically. To insure that the MAD 
subprogram being worked is modified physically, give a 
redundant WORK request using the name of the subprogram 
3 i ready being worked. Whenever a WORK request is given, the 
logical modifications associated with the subprogram 
previously being worked are made physically. To insure that 
the current user core image is modified physically, use a 
SAVE request. A user who cannot afford the added tracks can 
give an "execute delete" on the created SAVED file. This 
variation between the physical and logical modifications 
provides some degree of safety to the user who carelessly 
makes gross incorrect modifications to one of his programs. 
If the user should accidently type a "d" as a request line 
for example, he should quit by hitting the break button 
twice in succession. This will prevent MADBUG from actually 
deleting the file in question. 
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request 

SUMMARY OF MADBUG 
arguments 

REQUESTS 

add i t i onal 1 i nes ( 3 ) 

work 

subprogram name 

none 

print 

card names (1) 

card images by MADBUG 

delete 

card names (1) 

none 

i nsert 

card names (1) 

card images by user 

change 

card names (1) 

card images by user 

append 

none 

card images by user 


(or) subprogram names 

none 

man i pul ate 

special, then cards 

card names by MADBUG 

trans 1 ate 

none 

comments by MADBUG 

use 

subprogram names 

none 

go 

card name or none 

comments by MADBUG (4) 

open 

variables (1,2) 

values by both (4) 

verify 

variables (1,2,5) 

values by MADBUG (4) 

1 i nkage 

none 

1 i nkage by MADBUG (4) 

break 

card names ( 1 ) 

none (4) 

kill 

card names (1) 

none (4) 

save 

save-name 

none (4) 

res tore 

save-name 

none (4) 

quit 

none 

none 

execute 

command and arguments 

depends on command 

force 

parameter, special 

none 


notes: (1) If none, all are implied. 

(2) Optional form forcing first argument. 

(3) Any request can get error comments from MADBUG. 

(4) Comments by MADBUG if core image is created. 

(5) There is an optional save-name argument. 
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I dent i f i cat i on 

Post Mortem Debugging 
PM 

Purpose 

Produce post-mortem information about the user's last 
dormant program (loaded by the relocatable program loader). 

Restrictions 

The program should be loaded by LOAD or LOADGO so that the 
loader and movie table are available. 

Usage 

The PM command may be followed by one of several requests. 

PM ' I L C ' Gives the stop location or I LC (1 line). 

PM 'LIGHTS' Gives machine conditions and I LC (4 lines). 


PM 'STOP' 

PM 'AUTO' 
PM 'STOMAP' 

PM NAME 


Gives I LC and contents of two locations on 
either side of the stop (5 lines) 

Corresponds to LIGHTS plus STOP (9 lines.) 

Gives origin and entry of all subprograms 
1 oaded . 

Gives contents of four initial locations of 
subprogram NAME (5 lines). 


PM NAME LOCI L0C2 -MODE- -DIRECTION- 

Gives contents of all locations from relative 
location LOCI through L0C2 of subprogram NAME 
in the specified mode and direction. NAME is 
'(MAIN)' for the main program. LOC is assumed 
to be decimal; if the number is preceded by a 
slash, '/', it is taken as octal. MODE 
specifies the form of printed output and may 
be 'FIX', 'FL0', 'DEC', ’ 0CT ' , 'BCD', or 
'ALL'. DIRECTION specifies the order of 
printing and may be 'FWD' or 'REV'. If MODE is 
ommitted 'ALL' is assumed; if DIRECTION is 
omitted, 'FWD' is assumed. LOCI and L0C2 may 
be replaced by 'ENTIRE' to cause printing of 
the entire program. 


PM LOCI L0C2 -MODE- -D I RECTI 0N- 

Gives the contents of absolute locations LOCI 
thru L0C2. 
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References to COMMON must be the high core 
locations which appear in the assembly 
listing, not the lower core area actually used 
for COMMON. (Caution: illegal requests, 
either outside the program range or improper 
requests for COMMON, cannot be interpreted 
correctly.) 


* 
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I dent i f i cat i on 

Relocatable program patching 
PATCH/ STOPAT/ TRA 


Purpose 


To allow break po 
been loaded/ to a 
location/ and to 


ints to be set in a program after it has 
llow transfer of control to a specified 
allow modification of the loaded program. 


Restrictions 


These service routines are normally 
is loaded and so the loader must 
Therefore LOAD or LOADGO should be 
program. 


loaded after the program 
be available in core, 
used for loading the 


Usage 

Set a break point: 





STOPAT ENTRY RELLOC 


ENTRY is an entry point in the desired subprogram. 

If ENTRY is omitted/ the main program is 
assumed. 

RELLOC is the relative octal location in the 
specified subprogram at which the break point 
stop is to occur. 


STOPAT 


replaces the instruction at RELLOC with a 
transfer. When the transfer is executed/ the 
original contents of RELLOC is restored and 
the program is placed in dormant status. The 
START command may then be used to continue 
with the execution of the original contents ot 

RELLOC. 


Transfer : 


TRA ENTRY RELLOC 

Same argument specifications as STOPAT . The 
issuance of the START command will cause a 
transfer to RELLOC. This_ may be used to 
restart the program from different locations 
during debugging sessions. 


9 
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Modify the program: 


PATCH ARG 


ARG=entry: 


ARG may be the entry point of a subprogram 
w hich is to be patched by referring to 

I’nr. a ! :ive ocations within the subprogram. 

ARG is omitted, (MAIN) is assumed. 


If 


ARG='(ABS)' allows patches to absolute locations. 

ARG-'(COM)' allows patches to relative locations within 
the COMMON region. 


ARG='(PAT)' allows patches to be entered into locations 
above the user s current memory bound. This 
patch. space is referenced by relative 
locations and is shared by all subprograms. 

After a response from the PATCH command, the 
user enters lines of the form: 


LOC, TYPE, VALUE, RELOC 

LOC is the octal address to be patched. This octal 
number may be immediately followed by a 

ADr C i a1 !^ ter if ,t: ls desirable to override 
ARG for this response. The special letter may 
be A for absolute location, C for relative 
location In common, or P for a relative 
location in the patch space. 


TYPE is the ^ type of value to follow i.e., 

2? ta1 word (used for instructions) 
FLO , fixed or floating-point number 
(E or F notation) 

' I NT’ , fortran i nteger 
'DEC', MAD integer 


VALUE is the number to be patched into LOC. 

RELOC is the relocation specification for VALUE if 
TYPE is 'OCT'. It consists of two letters, the 
first for the decrement and the second for 
A: absolute 

R: relocatable 
C: common 
P: Patch space 


ir.SI L0C \ s om ' tted, AR is assumed. Successive 
VALUES and appropriate RELOCs may be specified 
In any line 

Exit from PATCH is the QUIT signal. 
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I denti fi cation 

Absolute program patching 
SPATCH 

Purpose 

Programs loaded with LDABS , NCLOAD, or VLOAD may be patched 
using some supervisor routines which do not require special 
loading and movie tables. This is accomplished by patching 
their SAVED file, rather than the core B program directly. 

SPATCH NAM El LGC A1 B1 A3 B2 ... An Bn 
SPATCH NAME 2 I LC L 


SPATCH patches the file NAME 1 SAVED beginning at 
absolute octal location LOC for n locations. 
If LOC is 'ILC', only the I LC of NAME1 SAVED 
will be patched, causing a transfer of control 
to absolute location L when NAME1 is RESUMED. 

Ai Bi are the octal left and right half words 
respecti vel y. 

L is the location at which control should be 
RESUMED. 

























■ 
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I dent i f 1 cat i on 

Supervisor debugging 
SD, SP 


Purpose 

To allow for printing and patching the supervisor (core A). 

The printing routine has several options: 


SD ENTRY RELOC N 


N consecutive locations starting at relative 
octal location RELOC in subprogram ENTRY in 
the supervisor will be typed on the user's 
console in unrelocated (i.e./ relative) octal 
with operation code mnemonics. If N is 
omitted, it is assumed to be 1. If ENTRY is 
omitted/ the request is taken to be absolute. 
Lines of zero are not supressed. 

SD ENTRY 'TRACE' 


The name 
relative 
was last 
console . 
typing a 


of the calling subprogram and the 
location from which subprogram ENTRY 
called will be printed on the user's 
The user may continue tracing back by 
carriage return. The trace may be 


terminated by the QUIT signal 


SD 'STOMAP' 


A storage map of all subprograms loaded into 
the supervisor's core (core A) will be 
pr i nted . 


SD ENTRY 

The contents of the specified entry will be 
printed on the user's console in appropriate 
form (BCD for LDNAME/ all others in 5 octal 
digits). 


Patch i ng: 

SP ENTRY RELOC A1 B1 Cl A2 B2 C2 ... AN BN CN 

Patching will begin in relative octal location 
RELOC within the subprogram ENTRY. Al Bl are 
the relocatable octal left. and . right 
half-words, respectively. The Ci contain two 
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characters indicating how the left and right 
? are u to be relocated. The characters 
may be A for absolute or R for relocatable. If 

fwtdv IS r?! tted ' lt is assumed to be AR. If 
ENTRY and Ci are omitted, the patching is 




•) 




CTSS PROGRAMMER'S GUIDE 


Section AH. 8. 07 


PAGE 1 


I denti f i cation 

STRACE - A trace debugging routine 
B.L. Wolman, x6022 

Purpose 

STRACE (Subroutine TRACE) is a debugging program which 
allows the user to monitor the calls of selected 

subroutines. A set of conditions may be specified for each 
subroutine to be traced. At each call of the subroutine, 
STRACE checks to see if all the conditions are met. If they 
are, STRACE prints a message identifying the subprogram 
called, how many times it has been called, the absolute 
location of the call, the program in which the call 

occurred, and the relative location within the program 
mak i ng the call. 

The user may request STRACE to STOP execution before 
executing a subroutine or to HALT after the subroutine has 
been called. If either of these options are used, STRACE 
will print an identifying message before going to dormant 
status. PM or QCTLK may be used to inspect the machine 

conditions. Issuing the START command will cause execution 

to continue. 

The user may also specify a debugging subroutine which is to 
be called before executing a subroutine. This debugging 
subroutine may perform any function the user desires; the 
call issued by STRACE is of the form 

DEBUGCLOC, ARG) 

where DEBUG is the debugging subroutine name, LOC is the 
location of the call to the subroutine being traced, and ARG 
is a parameter previously specified by the user. 

Options are also available which allow the user to obtain 
octal snapshot dumps of the machine registers, the 
subroutine calling sequence, and the value returned by the 
subroutine in the accumulator. 

Usase 

STRACE may be entered by issuing the CTSS command STRACE. 
Because of the method of implementation, the loader must be 
present in memory. The STRACE command may be issued 
immediately after loading, after a QUIT signal, or after a 
trace stop. (In general, STRACE may be entered any time the 
user's program is in dormant status). At the end of the 
input phase, STRACE will return to dormant in such a manner 
that the START command will cause execution to be resumed at 
the point where it was interrupted. 
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TRACE is an alternate entry which may be called as a 
subroiitme. In this case, TRACE returns to 1,4 in the 
calling sequence. The calls are of the following form 


AED 

MAD 

FORTRAN 

FAP 


TRACEO $, 
EXECUTE TRACE. 
CALL TRACE 
TSX $TRACE,4 


Wfle *? x!nr CE ' S ready f° r input or more input, it prints the 
word TYPE, and waits. After receiving this response! the 
user may enter a series of commands. Each command consists 
of a subroutine name followed by one or more requests 
Within a command, blanks are used to separate requests and 
thejr parameters. Since a carriage return is compteteW 
equivalent to a blank, commands may be split across one or 

The 2sr ° f lnPlJ V . Each co, . llmand is terminated by a comma. 
The last command is terminated by an asterisk which 
signifies the end of the input phase. 

Ind f“i'“ w i ng T? qUe 5 tS . ar f furrently recognized by STRACE (N 
and M are positive decimal integers less than 32768. DEBUG 
is the name of a subroutine). 


AFTER N - begin tracing after the Nth call of the 
subrout i ne. 

EVERY N - Trace every Nth call. N should be 
non-zero. 

UNTIL N - Trace until the Nth call. The AFTER 
condition should be less than the UNTIL 
cond i t i on. 


STUP N - Go to dormant before every Nth call. If 

N ‘ s zero, the STOP condition will be 
removed. 


HALT N - Go. to dormant after every Nth call. 
Execution will be interrupted after the 
specified subroutine has been executed and 
before it has returned to the program making 
the call. This request should not be used if 
the subroutine being traced has an error 
return or does not always return to the same 
point in the calling sequence. If N is zero, 
the HALT cond ition will be r emo ved . 

ARGS N - Every N times it is called, print the 
arguments of the subroutine. Each word in 
the calling sequence is assumed to specify a 
single variable. The absolute and relative 
addresses . of these variables and their 
contents will be printed in octal. The 
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relative location will be "****" whenever the 
specified location is in COMMON or is in turn 
an argument of the subroutine making, the 
call. Whenever N is zero, the ARGS condition 
will be removed. 

VALUE N - Print the value of the specified 
subroutine. The value of the subroutine will 
be obtained by interrupting execution in the 
same manner as the HALT request; the same 
restriction applies. The VALUE condition 
will be removed whenever N is zero. 

PM N Ml W2 ... Wn - Every N times the specified 
subroutine is called, print an octal snapshot 
dump of the machine registers specified by 
the parameters W1 to Wn. The Wi's may be any 
of the following words. 

AC Accumulator, Q and P bits 

MQ Multiplier-quotient register 

SI Sense indicators 

MB Memory bound 

XI Index register 1 

X2 index register 2 

X 3 Index register 3 

X4 Index register 4 

X5 Index register 5 

X6 Index register 6 

X7 Index register 7 

Li First location in subroutine calling sequence 

L2 Second location in calling sequence 

L3 Third location in calling sequence 

Cl First argument of subroutine 

C2 Second argument of subroutine 

C3 Third argument of subroutine 

XS Equivalent to the sequence XI X2 X3 X4 X5 X6 X7 

ALL Equivalent to the sequence AC MQ SI MB XS 

If any of the above words appears with an initial minus sign 
in the request, the PM of the corresponding register(s) will 
be removed. Because the PM request has a variable number of 
parameters, it must be the last request of. any command. The 
PM print occurs after any call of a debugging subroutine and 
before any stop. The request PM 0 will suspend all PM 
requests for the particular subroutine. 

CALL N DEBUG M - Before every Nth call, execute 
the debugging subroutine DEBUG with parameter 
M. If N is zero, the CALL condition will be 
removed; in this case the debugging 
subroutine name and the parameter M should 
not appear. If M is zero, the parameter used 
in the call of DEBUG will be the number of 
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times the subroutine being traced has been 
executed,. If both the STOP condition and the 
CALL condition are simultaneously satisfied / 
the CALL of the debugging subroutine will 
occur before the STOP. 

COUNT N - Reset the execution count of the 
subroutine to N. This request may be used to 
continue tracing after the UNTIL limit has 
been reached. 


REMOVE - Remove the subroutine from the internal 
trace table. After this request has been 
given, STRACE will have no record of or 
control over calls to the subroutine. 


OFF - Turn. off tracing of this subroutine. All 
succeeding calls will be ignored until 
tracing is restored via the ON request. 

ON - Restore tracing of this subroutine. 


FIND - Print the entry point of the subroutine. 
Any requests after the FIND will be ignored. 
FIND should only be used if no tracing is 
desired, since entry points are automatically 
printed the first time a subroutine name is 
encountered during the input phase. 


If no request is given following the subroutine name, 
standard requests 


the 


AFTER 0 EVERY 1 UNTIL 32767 STOP 0 
CALL 0 HALT 0 ARGS 0 VALUE 0 PM 0 

are assumed. Any requests given by the user override the 
corresponding standard value. Any of the tracing parameters 
° ' a subroutine may be changed by the user in a later entry 


Method 


When STRACE is asked to trace a subroutine, it saves the 
name of the subroutine in an internal table. STRACE 
searches the MOVIE) table for the named subroutine. If it 

.’i* STRACE obta j ns the entry point. STRACE then uses 

the MOVIE) table to find the origins of all programs in 
core. When it finds a program that has a transfer vector 
it searches this transfer vector for a TTR to the subroutine 
entry point. If a TTR is found, it is changed to a TXL 

TRAP,, TABLE where TRAP is the address of the trace 

processing section of STRACE and TABLE is the index of the 
subroutine being traced in the internal trace table. 
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The REMOVE request causes essentially the inverse operation 
to be performed. All TXL TRAP/, TABLE instructions are 
changed to TTR ENTRY and the subroutine is removed from the 
internal table. 

During execution of the user's program a call to a traced 
subroutine will result in a TSX to the TXL instruction in 
the transfer vector. The TXL instruction will transfer to 
the appropriate section of STRACE. Using the contents of 
index register 4, STRACE obtains the TXL instruction and 
checks to see if it is legal (i.e., does the table position 
indicated by the decrement actually correspond to a 
subroutine name?). If the TXL is legal, STRACE retrieves 
the tracing conditions for this subroutine and checks them. 
Depending on the conditions and the number of executions of 
the subroutine, STRACE may print the trace message before 
transferring to the subroutine. 

When the HALT or VALUE requests have been specified, STRACE 
examines the subroutine calling sequence to determine where 
the subroutine will return. It then saves the instruction 
at the return point and the instruction immediately 
following in the trace table and replaces them with a 
transfer back to STRACE. When STRACE obtains control 
following the execution of the subroutine it restores the 
two instructions. If the subroutine does not return 
correctly the breakpoint will not be removed and the two 
instructions which were saved will be destroyed the next 
time the HALT or VALUE condi tion(s) are satisfied. 

The call of the debugging subroutine and the execution stop 
occur just before the transfer to the traced subroutine. In 
both cases the user's machine conditions (with the exception 
of index register 4) are restored. 

Rest r i c tiona 

Unly 20 subroutines may be traced at one time. This limit 
is somewhat arbitrary and may be increased in the future. 

STRACE will correctly handle any subroutine that is called 
by an instruction of the form TSX SUB, 4. A subroutine such 
as ( I OH) which is entered by the instruction TRA* (I0H) 
canno t be traced. A subroutine should not be traced if 
there is anv indirect reference to it through the transfer 
vector. 

ERROR MES SAG ES 

The following error messages are currently implemented 

TRACE TABLE FULL - No more subroutines can be traced 
until the REMOVE request is used. 
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NAME IS NOT IN TRACE TABLE - The user has attempted to 
use the ON, OFF, or REMOVE requests for subroutine NAME 
which is not in the internal trace table. 

NAME IS NOT USED - Subroutine NAME has been loaded but 
is not called by any program. All requests for this 
subroutine are ignored. 

NAME IS NOT IN MOVIE TABLE - Subroutine NAME has not 
been loaded. All requests pertaining to this subroutine 
will be i gnored. 

NAME IS NOT A REQUEST ~ STRACE does not recognize the 
request NAME. This word and the next word of input (most 
requests have a parameter) will be ignored. If the command 
line seems to be fouled up, the user can recover by typing a 
comma to terminate the command and then retype the entire 
command. 


NAME PARAMETER MISSING, REQUEST IGNORED, 
typed a sequence such as AFTER, or UNTIL,, 
for the request NAME is missing, since the 
terminated by the comma, the user must 
command. Note that the command 


~ The user has 
The parameter 
command was 
enter another 


SIN AFTER UNTIL 2, 

will result in the comment 2 IS NOT A REQUEST. 


BAD CALL OF TRACE FROM LUC - There has been a spurious 
transfer into STRACE or else location LOC ( the word pointed 
to by the instruction at 0,4 ) contains a TXL 
which has an illegal decrement. The decrement 
TXL instruction should be less than 201 (for 
limit of 20 entries) and a multiple of 10. 
machine conditions will be restored, and STRACE 
dormant. 


i nstruct ion 
of a legal 
the current 
The user's 
will go to 


NAME IS NOT A LEGAL PM - STRACE does not recognize 
word NAME as a legal PM parameter, it will be ignored. 


the 


NO DEBUGGING SUBROUTINE, CALL IGNORED. - The 
^®i"£Otten to supply the name of the debugging 
The CALL condition will be r emo v e d . 


user has 
subrout i ne. 


Disclaimer 


. This version has been checked and debugged, although no 
claims are. made in this respect. Any comments, suggestions, 
and/or modifications will be welcomed. In case of trouble, 
contact Barry Wolman, Room 532 T.S., Ext. 6022. 
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Identification 


create and edit 12-bit BCD 
command permits editing and 

revising uy uumuca.-, than by line, number. The 
command RUNOFF will print out a 12-bit BCD line-marked file 
in manuscript format. RUNOFF contains several special 
features which were not available with the DITTO command/ 
including type-justification. 


Manuscript typing and editing 

TYPSET, RUNOFF 
J. Saltzer, X6039 

Purpose 

The command TYPSET is used to 
line-marked files. This 

• _ ! l_ . . /N v/ F k afhor 


References 


This work represents one more iteration in the arduous, task 
of creating an "ultimate" editing scheme. As such/ it is 
primarily a synthesis of techniques which have been proven 
valuable in several separate problem areas. It is felt that 
this particular synthesis brings to bear, on the editing 
problem an easy to use package of techniques/ and mighty 
provide a model for an editor on a next generation 
time-sharing system. Here is a list of some of the sources 
of ideas for these commands: 


J. McCarthy 
S . Pi ner 
P. Samson 

Comp. Center staff 
M. L. Lowry 
M. P. Barnett 
V. H. Yngve 
R. S. Fabry 
A. L. Samuels 
F. J. Corbato 


(Colossal typewriter) 
(Expensive Typewriter) 

( Justi f y) 

( I nput/ edi t/ and file) 
(Memo/ Modify, and Ditto) 
( Photon) 

(Comit/ Vedit) 

(Madbug) 

(Edi ts) 

(Revi se) 
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An Edit-by-Context Program 


Program Name : TYPSET 

Description 


TYPSET is a command program used to type in 
memorandum files of English text. TYPSET 
command RUNOFF, is an alternative to the 
MODIFY, and DITTO. Editing is specified by 
than line number, and input is accomplished 
since the program does not respond between 1 


and edit 
along with the 
commands MEMO, 
context, rather 
at high speed 
i nes . 


Usa ge, 


TYPSET name 


"name" specifies 


of a 
file 


file 
i s 


to be 


the primary name of 


request. 


. a file to be edited, or 
tn . _ f a 5 ed; i* may be absent, in which case a 
to be created, and must be named later by the "FILE" 



Hj gh - Speed Input Mode 

In high speed input mode, the user may type lines of ud to 

epara?ed C br S ! ength (e ' s '' 120 "characters) 

separated by carriage returns. He does not wait for 

response from the program or the supervisor between lines 
but may type as rapidly as desired. The full character set 
of his keyboard may be used. cter set 

The user leaves high-speed input mode and enters edit mod P 
by typ.ng an extra carriage return. When swUching modes 
the program acknowledges the switch by typing the name of 
the new mode, "input" or "edit". of 


Edit Mode 


In edit mode, the program recognizes "requests" of the form 

Sf V the f ?:* h An re< ™ take effect Immediate?! on a copy 
ot the file being edited. Except where a reauesf it 

expected to cause a response, such as "PRINT," successive 
requests may be entered immediately on successive lines 
w.thout waiting for a response from the prog?!: Each 


separa te 
from the 


request must begin on a separate line, 
program are generally typed in red. 


Responses 
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Requests 

Editing is done line by line. We may envision a pointer 
which at the beginning of editing is above the first line of 
the file. This pointer is moved down to different lines by 
some requests, while other requests specify some action to 
be done to the line next to the pointer. All requests 
except FILE may be abbreviated by giving only the first 
letter. Illegal or misspelled requests will be commented 
upon and ignored. 

For purposes of description, the requests have been divided 
into two categories, those necessary for effective use of 
the command, and special-purpose requests which are not so 
generally useful. The first category includes eight 
requests : 


LOCATE character string 

This request moves the pointer down to the first line 
which contains the given character string. Only enough 
of the line need be specified to identify it uniquely. 
Since the pointer only moves down through the file the 
second occurrance of a line containing a given 
character string may be located by giving the LOCATE 
request twice. The line which has been found is 
printed in its entirety. 

It is not necessary to count blank characters exactly. 
If one blank character appears at some point in the 
request string, any number of blank characters or tabs 
at the corresponding point in the file will be deemed 
to satisfy the request. If 2 blank characters appear 
together in the request string, there must be at least 
two blank characters or tabs at the corresponding point 
i n the file, etc. 

If the LOCATE request fails to find a line containing 
the given character string, a message is printed, and 
the pointer is set to point after the last line in the 
file. Any requests which were typed in between the 
LOCATE which failed and the message from the program 
about the failure are ignored. Another LOCATE request 
will move the pointer back to the top of the file to 
begin another scan down through the file. 

PRINT n 


Starting at the pointer, n lines are printed on the 
typewriter console. The pointer is left at the last 
line printed. If n is absent, 1 line is printed and 
the pointer is not moved. If the pointer is not at a 
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line (e.g., above or below the file/ or at a line just 
deleted) only a carriage return is typed. 

NEXT n 

This request moves the pointer down "n" lines. If "n" 
is absent/ the pointer is moved to the next line. 

DELETE n 

This request deletes "n" lines/ starting with the line 
currently being pointed at. The pointer is left at the 
last deleted line. If "n" is absent/ the current line 
is deleted and the pointer not moved. 

INSERT new 1 i ne 

The line "new line" will be inserted after the line by 
the pointer. The first blank following the request 
word is part of the request word, and not part of the 
new line. The pointer is set to the new line. To 
insert more. than one line/ give several INSERT 
requests/ or just type a carriage return to switch to 
high-speed input mode. All lines typed are inserted 
after the line being pointed at. When the user returns 
to edit mode by typing an extra return, the pointer is 
set to the last inserted line. If the very first edit 
request given is an INSERT, the inserted lines are 
placed at the beginning of the file. If an INSERT is 
given after the pointer has run off the bottom of the 
file, the inserted lines are placed at the end of the 
file. 

CHANGE "string l"string 2" n G 

t ,n the line. being pointed at, the string of characters 
^string 1 is replaced by the string of characters 
string 2 . Any character not appearing within either 
character string may be used in place of the double 
quote character. If a number, "n", is present, the 
change request will affect "n" lines, starting with the 
one being pointed at. All lines in which a change was 
made are printed. The last line scanned is printed 
whether a change was made or not. The pointer is left 
at the last line scanned. If the letter "G" is absent, 
only the first occurrence of "string 1" within a line 
will.be changed. If "G" is present, all occurrences of 
string 1 within a line will be changed. Blanks in 
CHANGE-request strings must be counted exactly. 

Exampl e : 

^' ne: It is a nice day in Boston. 

request: CHANGE "is"was" 
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new line: 
request : 
new line: 

request: 

new line: 
request : 
new line: 
request : 
request : 
request : 
new line: 


It was a nice day in Boston. 

CHANGE xwasxisx 

It is a nice day in Boston. 

CHANGE ' g 

It. is. a. nice. day. in. Bos ton. 

CHANGE 

I ti s.a.ni ce.day. i n. Boston. 
CHANGE "tis"t is" 

CHANGE ' G 

CHANGE 'on 'on.' 

It is a nice day in Boston. 


F I LE name 

This request is used to terminate the editing process 
and to write the edited file on the disk. The edited 
file is filed as "name (MEMO)". If "name" is absent, 
the original name will be used, and the older file 
deleted. If no name was originally given, the request 
is ignored and a comment made. When this request is 
finished, the user returns to command level, and the 
supervisor will respond by typing "R" and the time 
used. 


TOP 

This request moves the pointer back to above the first 
line in a file. 

The following seven requests are handy for special purposes, 
but will probably not be used as often as the ones 
previously described. 

BOTTOM 

This request moves the pointer to the end of the file 
and switches to input mode. All lines which are then 
typed are placed at the end of the file. 

ERASE c 

The character "c" becomes the erase character. 

Normally, the character "#" is the erase character. 

(The erase character is used to delete the previously 

typed character or characters.) 

KILL c 

The character "c" becomes the kill character. 

Normally, the character "±" is the kill character. 
(The kill character is used to delete the entire line 
currently being typed.) 
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VERIFY p 

If the parameter, "p" is "OFF", the following program 
responses are not automatically typed: 

INPUT" or "EDIT" when the mode is changed. 
Lines found by the FIND or LOCATE requests. 
Lines changed by a CHANGE request. 

If the parameter "p" is "ON", the responses are 
restored. The command begins in "ON" mode. 

RETYPE new 1 i ne 

The line "new line" replaces the line being pointed at. 
The first blank following the request word is part of 
the request word and therefore is not part of the new 
line. 

FIND character string 

This request moves the pointer down to the first line 
which starts with the given character string. 

SPLIT name 

All the lines above the pointer are split into a file 
named "name (MEMO)". Any old copy of "name (MEMO)" is 
deleted. The remainder of the file may still be 
edited, and filed under another name. The SPLIT 
request may be used several times during a single edit, 
if desired. Unless at least one "TOP" request has been 
given, "name" must be different from the original name 
of the file being split. 


Backspac ? ng 

The backspace key may be used to create overstuck or 
underlined characters. All overstruck characters are stored 
In a standard format, independent of the way they were typed 
in. CHANGE-, LOCATE- and FIND-request strings are also 
converted to this standard format, so it is not necessary to 
remember the order in which an overstruck character was 
typed in order to identify it. For example, suppose the 
line: 

The N0RMAL M0DE statement of MAD 

had been typed in by typing the letters NORMAL, five 
backspaces, a slash, and four forward spaces. The slashed 0 
can be changed to a normal 0 by typing 
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CHANGE ' 0 ' 0 1 


Restr i ctedNames and Recovery Procedures 

Two special names are used for intermediate files by TYPSET. 
They are: 


(INPUT (MEMO) 

(INPT1 (MEMO) 

Following a quit sequence (or a CTSS system breakdown) one 
of these files may be found. (Whenever a quit sequence has 
been given, a SAVE command should be issued to save the 
status of all files.) Since the intermediate file generally 
contains a complete copy of the file at the end of the last 
pass, it may be renamed and used as a source file, and may 
permit recovery of lost requests. The original file is 
never deleted until the new, edited file has been 
successfully written and closed. 

The user's disk status and file directory are updated at the 
end of each pass through the file, thereby providing 
additional insurance against accidental loss. 

The intermediate files are normally written in permanent 
mode. If the user's track quota becomes exhausted while 
editing, TYPSET will switch to temporary mode intermediate 
files. If it is necessary to leave the edited file in 
temporary mode, a comment will be made. 
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Summary of TYPSET requests. 


abbrev. 

request 

response 

Basic requests: 



L 

LOCATE string 

1 i ne found * 



end-of-f i 1 e 

D 

DELETE n 

end-of -f i 1 e 

N 

NEXT n 

end-of-f I 1 e 

1 

1 NSERT 1 Ine 

none 

P 

PRINT n 

printed 1 ines 



end-of-f i 1 e 

C 

CHANGE QxxQyyQ n G 

changed lines 

T 

TOP 

none 


FILE name 

Ready message 

Special purpose 

requests : 


B 

BOTTOM 

"Input" * 

V 

VERIFY ON (or OFF) 

none 

S 

SPLIT name 

no name given 

R 

RETYPE new 1 I ne 

none 

E 

ERASE x 

none 

K 

KILL x 

none 

F 

FIND string 

1 I ne found * 



end-of-fi le 


* These responses will not occur if VERIFY mode is off. 


V 
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A Right-Justifying Type Out Program 


Program Name : RUNOFF 

Program Descr i pt i on 

RUNOFF is a command used to type out memorandum files of 
English text in manuscript format. Control words scattered 
in the text may be used to provide detailed control over the 
format. Input files may be prepared by the context editor, 
TYPSET. 

RUNOFF NAME1 -'NOSTOP'- -N- 

where "NAME1" is the primary name of a file "NAMEl (MEMO)" 
to be typed out. If a number, "N" is present, typing starts 
with the page numbered "N". The optional parameter "NOSTOP" 
is explained below, under " Non - Stop Typing ." 

Control Words 

Input generally consists of English text, 360 or fewer 
characters to a line. Control words must begin a new line, 
and they begin with a period so that they may be 
distinguished from other text. RUNOFF does not print the 
control words. 

.append A 

Take as the next input line the first line of A (MEMO), 
.line 1 ength n 

Set the line length to "n". The line length is preset 
to 60 . 

.indent n 

Set the number of spaces to be inserted at the 
beginning of each line to "n". Indent is preset to 0. 

.undent n 

In an indented region, this control word causes a 
break, and the next line only will be indented n spaces 
fewer than usual. This control word is useful for 
typing indented numbered paragraphs. 

.paper length n 

This control word is used for running off a memorandum 
file on non-standard paper. The number "n" is a line 
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count/ figured at 6 lines per inch. If this 

word is not given, "n" is assumed to be 66, for 
paper. 


contro 1 
11-inch 


.single space 


Copy is to be single spaced. This mode takes effect 

after the next line. (The normal mode is single 
space.) & 

.Double space 

Copy is to be double spaced. This mode takes effect 
after the next line. 


.begin page 


Print out this page, start next line on a new page. 
. ad j us t 


Right adjust lines to the right margin by inserting 
blanks in the line. The next line is the first one 
affected. (This is the normal mode.) 

. no just 


Do not right-adjust lines. 


.fill 


Lengthen short lines by moving words from the following 
line; trim long lines by moving words to the following 
line. (This is the normal mode.) A line beginning 
with one or more blanks is taken to be a new paragraph, 
and is not run into the previous line. 

. nof i 1 1 

Print all lines exactly as they appear without right 
adjustment or filling out. 

.page -n- 

Print page numbers. (The first page is not given a 
page number. It has instead a two-inch top margin.) 
! f . n is Present, print out the present page 
immediately, and number the next page "n". 
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.space -n- 

Insert "n" vertical spaces (carriage returns) in the 
copy. If "n" carries spacing to the bottom of a page# 
spacing is stopped. If "n" is absent or 0, one space 
i s i nser ted. 

.header xxxxxxxxxxxxxxxx 

All of the line after the first blank is used as a 
header line, and appears at the top of each page along 
with the page number, if specified. 

. break 

The lines before and after the .break control word will 
not be run together by the "fill" mode of operation. 

. center 

The following line is to be centered between the left 
and right margi ns . 

.literal 

The following line is not a control word, despite the 
fact that it begins with a period. 

All control words may be typed in either upper case or lower 
case. Illegal control words are ignored by the RUNOFF 
command. A comment may appear to the right of a control 
word, as long as it is on the same line. 


Manuscr i ot Conventions 

The RUNUFF program assumes a page length of 11 inches, with 
6 vertical lines per inch. The top and bottom margins are 1 
inch, except for the first page which has a 2-inch top 
margin. if page numbers are used, they appear flush with 
the right margin, 1/2 inch from the top of the page. If a 
header is used, it will be on the same line as the page 
number. The first page is not numbered, or given the header 
line unless the control words ".header" and .page 1 appear 
before the first line of text. 

Customary margins are 1 1/2 inches on the left and 1 inch on 
the right, implying a 60-character line. This is the 

standard line length in the absence of margin control words. 

The program stops between pages and before the first page 
for loading of paper. The paper should be loaded so that 
after the first carriage return typing would take place on 
line 1 of the paper. The left margin stop of the typewriter 
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s h°uld be placed at the point typing will begin, 
right margin moved as far right as possible. If 

type the first carriage return, the program will 
typing. 


and the 
you now 
con t i nue 


labs 


Tabs included inthe text are faithfully reproduced in the 
mal copy. Since there will be interactions between 
inserted tabs and the right-adjust and fillout procedure 
the control word ".nofill" should precede any use of tabs! 

• y° u wis h to indent, say, a whole paragraph, with 
right-adjustment and filling, change "indent" and "line 
ength rather than using a tab at the beginning of each 
line. In order to type out a memo which uses tabs, the 

proper 1 y^ ^ Stops and left margin must be set up 


backspaci ng 


Underlining or overtyping may be accomplished with the 
of the backspace key, even in a line that is subject 
right adjustment. 


a i d 
to 


ii£Xl--S- fc9 P Typing 


If continuous form paper is used, RUNOFF can 
not to stop between pages by inserting 
NUSTuP" after the file name (and before an> 
number) when the command is typed, e.g. 


be instructed 
the parameter 
initial page 


RUNOFF ALPHA NOSTOP 


Abbrevi ations 


All control wordsmay be abbreviated if desired. A list of 
abbreviations is given in the summary. In most cases, a 
single word is abbreviated by giving its first two letters* 
two words are abbreviated by giving the first letter of each 

W U I u « 
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Summary of RUNOFF Control Words 


abbrev. 

control word 

automat i c 

.ap 

.append A 

no 

.11 

.line 1 ength n 

no 

.pi 

.paper length n 

no 

. i n 

. i ndent n 

no 

. un 

.undent n 

yes 

. ss 

.single space 

yes 

. ds 

.double space 

yes 

. bp 

.begin page 

yes 

.ad 

. adj ust 

yes 

.f i 

.fill 

yes 

. nf 

. nof i 1 1 

yes 

• nj 

. noj ust 

yes 

. pa 

.page (n) 

yes 

. sp 

.space (n) 

yes 

. he 

.header xxxx 

no 

.br 

. break 

yes 

. ce 

. center 

yes 

. 1 i 

.literal 

no 


break 


, i f n 


If "automatic break" is yes, the lines before and after the 
control word will never be run together, and the previous 
line will be printed out in its entirety before the control 
word takes effect. 
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Identification 

Documentation of program changes 
LOG 

Pur po s e 

The LOG command has been designed primarily to provide a 
convenient way of bookkeeping information among users 
working on the same programs. 

Another related usage is to supply any user with a permanent 
way of obtaining information about the latest modifications 
in CTSS. 

Format 


LOG -CF- -NAM El- -NAME 2- 
CF is a common file number/ (0/ 1/2/3/ or 4) 

NAME1 and NAME2 are the names of a log file to which all new 
information is added/ and kept in the specified common file 
CF. If NAME 2 is missing it is assumed BCD. If NAM El and 
NAME 2 are missing/ they are assumed SYSLOG BCD. If CF is 
also missing it is assumed 2. 

Execution 

The LOG command begins by printing the contents of the file 
NAM El NAME2/ if it exists# so that the user is reminded of 
the latest modifications which he or other users might have 
made in the same programs. An interrupt will terminate 
printing. LOG then chains to the INPUT command so that the 
user may type whatever information he wishes to add to the 
log file. 

This information# along with a problem and user, number# 
system code# date# and time# is recorded at the beginning of 
the previous log file. Due to this procedure# the latest 
information is always available at the beginning of the 
file. 


CTSS Modification Bookkeeping 

Modifications to the CTSS system are usually recorded in the 
file SYSLUG BCD kept in the system files. Any user may copy 
this file by using the following command 

CUPY S SYSLUG BCD 
The file may then be printed. 
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LOG Structure 


The LOG command uses other system 
UPDATE/ EDIT/ FILE, COMBIN/ PRINTF. 
in using LOG In a chain of commands. 


commands, viz. COPY/ 
There Is no restriction 


Some imperfections in 
result in meaningless 
breaking the chaining 
el imi nated gradual 1 y 
system command. 


the commands called 
messages/ or in an 
set up by LOG. Such 
by improvements in 


on by LOG may 
abnormal exit 
f 1 aws will be 
each particular 


Suggest ? on 

ne ?. rec °rded in the log file starts with *b*b*b 

heading the line containing the user's identification and 

wi?h\h c S *V gg ? sted that no "ne typed in by users begin 
with this particular pattern. This would provide an easy 

retrfevar 006 ^- 1 °f fMeS aut omat i ca 1 1 y for information 
retrieval/ sorting by user/ etc. 
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I dent i f i cat i on 

Users talk to GOD 
REMARK 


Purpose 

Users may address themselves to "whom it may concern". The 
users' remarks file is printed off-line each day and the 
operations staff directs the printed copy to the appropriate 
members of the systems programming staff. 

Usage 


REMARK NAME1 NAME2 

The 6-bit BCD file NAME1 NAME2 which contains 
the user's remarks is appended to a PUBLIC 
file called USER REMARK. This file is printed 
each day by the operations staff and delivered 
to the addressees. If NAME2 is omitted, it is 
assumed to be BCD. If NAME1 and NAME2 are 
omitted, instructions for using the command 
are printed. 
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1 dent i f i cat i on 

INFO - An on-line documentation system 
J. Winett - X81-301 



Purpose 

In order to better provide information about the programs 
associated with the Compatible Time-Sharing System an 
on-line system for documenting computer programs has been 
developed. The design of this on-line system attempts to 
satisfy the following objectives: 

a) Have up-to-date information available to the 
user on request, thus eliminating the delays 
which occur in any memo distribution system. 

b) Have the ability to get specific information on 
request, e.g. the author of a routine, .as well 
as the complete documentation of a routine.. 

c) Give textual output in steps, i.e., printed 
according to information item types, and 
indicating the amount of printout that will 

result. , , 

d) Provide the facility to search through the 
library of programs to determine the programs 
which satisfy particular conditions. 

e) Standardize the format of the program 
description by requiring that when a new program 
is added to the system all information of 
interest be provided. 

f) Permit editorial control of the program 
documentation that is to be available on-line. 


The information describing a program is divided into 
information items. Each i tern of information is associated 
with an i tem DfllBfi and is referred to as the jjLfilfl 
the associated i_L£IQ nainfi* For example, the item vajue 
"WINETT" is associated with the item name AUTHOR . n 

following items of information indicate what is required as 
documentation of a computer program: 


1. Program NAME (N) - A single word. 

2. Program TYPE (T) - One of the following: 

COMMAND, ENTRY, LIBRARY, or PUBLIC. 

3. DESCRIPTORS (D) - Key words used to classify the 
programs in the information files. 

4. PURPOSE (P) - A short abstract or sentence 

description indicating the context in which a 
program might be used. 


0 
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5. USAGE (U) - The instructions of how to use the 
program/ e.g./ the calling sequence. 

6. Programming LANGUAGE (L) - The language in which 
the program is written. 

7. REFERENCE (R) - A bibliography of the program. 

8. AUTHUR (A) - The name of the person who is 
responsible for the program. 

9. DATE (DA) - The date the information was last 
entered or modified. 

Additional information items may also be defined/ e.g. 
program size/ transfer vector/ etc./ but the above items are 
considered to be required to document any program. 

Usage 

A model of this information system has been implemented as a 
CTSS command program with command name INFU. The system may 
be initiated as a console command or chained to from another 
program. If/ when the INFO system is called the NAME of a 
program is given as a command parameter/ the documentation 
on that program will be printed after which the system will 
call CHNCQM. This procedure allows other command programs 
to access their own documentation. For example/ when no 
parameters are supplied with a command which requires at 

least one parameter/ the command should chain to the INFO 
command with the command name as a parameter. This 
technique provides a means of tying the documentation of a 
command program to the command itself. 

If only the command name INFO is typed the system will 

res pond 

TYPE REQUEST/ OR C.R. FOR INSTRUCTIONS.. 

whereupon a carriage return will initiate the request to 
describe the INFO command. 

Alternatively/ requests can be typed to the INFO system. 
There are three classes of requests: a) Retrieval requests 
to obtain information from the system, b) Storage requests 
for adding, changing/ or deleting information from the 
system, and c) System requests wh i ch affect the operation 
of the system. The Retrieval requests - DESCRI BE (D), LIST 
(L), and F I NO (F) are to be used by all CTSS users. The 
Storage requests - STORE (S), ED I T (E), ALTER (A), and 

REMOVE (R) - are to be used by the people responsible for 

the information stored within the system. The System 
request - uU I T - is used to terminate communications with 
the system, and the requests - END . TSSF I L > and USRF I L - are 
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used for changing the operation of the system. Whenever the 
INFO system prints a comment followed by two periods/ it is 
the user's turn to type. After processing each request/ the 
system types 


OK. 


To obtain a description of a Storage or Retrieval request 
the user types the request name only. A request to the INFO 
system indicates three types of information: 1) an 
imperative request to the system/ 2) a list of single 
information words, and 3) information items specified by 
item names together with the item values associated with the 
item names. A request to the system is assumed to be 
indicated by one of the first few words typed. Other words 
following the request name may be item names and are added 
to a list of "information words" or may specify the values 
of information items and are added to a list of pairs 
consisting of an item name and its value. _ When the word 
"IS" or "ARE" is encountered in a request it is assumed that 
the previous word is an item name and that the following 
words form the item value. The input specifying the item 
value must be terini nated by a comma (or the carriage return 
at the end of the request) and may be followed by other item 
names and their values or by item names alone. If the word 
"THEN" appears as an information word the input scanned so 
far is assumed to constitute a request. After the request 
is processed, the input following the word "THEN is scanned 
for the specification of another request. Thus the word 
"THEN" indicates the termination of a request and allows 
multiple requests to be typed. Words other than item names 
or item values or the word "THEN" may be typed but are 
i gnored. 

Requests and item names may be abbreviated by their first 
letter (except the item name DATE which is abbreviated DA). 
If an item value is specified more than once in an input 
request the value last specified takes precedence. _ Thus, 
the on-line user may change or correct the specification of 
an item value by retyping the item name together with the 
item value in the same input request. 


To continue 
the carriage 
what to do. 


the typing of a request on another line precede 
return (C.R.) by a dash (-). When in doubt of 
type a carriage return. 
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RETRI EVAL REQUESTS 


1* The DESCRIBE (D) request! 


DESCRIBE NAME IS name, i(l)...i(n) 


This request is used to obtain the 
program whose name is known. The input 
gives the program name and the names of 
information. If no item names 


documentation of a 
with this reques t 
the des i red i terns of 
are specified, the 


information on ail items will be printed. For example^ 
DESCRIBE THE COMMAND WHOSE NAME IS INFO 


produces all the documentation associated with the INFO 
command, and 


D N IS INFO, USAGE 

prints just the item USAGE for the INFO program. 

When more than five lines of text are to be printed, the 
INFO system informs the user of the number of lines which 
follow. After realizing how much information will be 
printed, the on-line user may terminate the request by 
pressing the CTSS i nterrupt or aui t button. 


the user 


may 

to 


type 

type 


! ( f the i nterrupt button is pressed 

'CONTINUE (C)" to resume printing or "RESTART (R)" to type 
another request. Printing will be resumed approximately ten 
lines after the line at which printing was interruDted. 
(This is due to the fact that the CTSS output 
cleared on interrupt.) Since a number of lines 
interrupt, the process of interrupting and continuing 
provides a means of skipping lines of documentation. 
Unfortunately, this procedure gets very poor response 
CTSS. 


i nter rupted , 
buffers are 
are lost on 


from 


If the , QU i t button is pressed, the on-line user may type 
another command or type the CTSS command "START" to continue 
as described above. This procedure gets very much better 
response from CTSS. 


2. The LIST (L) request: 

LIST i ( 1) . . . i ( n) , TYPE IS type 

This request is used to obtain a list of all available item 
names, a list of the available values of certain information 
items, or a list of the names of all CTSS programs of a 
particular type. The request may ask for the values of one 
or more of the following items to be listed: 
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ITEMS, AUTHORS, DESCRIPTORS, 

LANGUAGES, TYPES, or NAMES 

or may also request a list of all CTSS programs of a 
particular type by typing either or both of the types 

COMMAND or ENTRY 

after the words: 'TYPE IS' . The list of programs of a 
particular type is obtained directly from CTSS and thus is 
au tomat i cal 1 y provided the mos t u p— to-date list of programs 
available. A request to 

LIST NAMES 

causes a list of commands and entries to be printed. A list 
of descriptors may be obtained by typing 

LIST THE DESCRIPTORS 


or just L D 


3. The F I ND (F) request: 

FIND i(l) IS vCl), . . . , i ( n) IS v(n) 

This request is used to perform a search for the program or 
programs which have particular information item values. The 
items to be matched are given by typing the item names 
together with their item values. Acceptable items for 

searchi ng on are: 

TYPE, DESCRIPTORS, AUTHOR, DATE, and LANGUAGE. 

A date value must be given in the form "DATE IS mm/dd, 
where inm is a numerical month and dd is a numerical day. 
All programs whose date is greater than that given will be 
printed. Note that a year is not specified and hence 
January is less than December (This bug will soon be 
eliminated). Descriptors are single words typed in any 
order and separated by spaces or the word "AND". 

For example, to find the commands which were documented 

since January 1 and have at least the descriptors UTILITY 
AND EDITING, type - 

FIND TYPE IS COMMAND, DATE IS 1/01, DESCRIPTORS - 
ARE UTI LITY AND EDITING 
o r 

F T IS C, DA IS 1/01, D ARE UTILITY EDITING . 

(note the use of the dash to continue the input request on 

the next line.) 
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system asks whether 1 th^user ^vants £" enty patching items the 

The user may then type "YES" or "NO" Fn^" 1 ^ the search * 

matching items the user s given the'oJ? 6a f tWenty more 

given the option of continuing. 
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STORAGE REQUESTS 


4. The STORE (S) request: 

STORE NAME IS name/ FILE IS file/ i C 1 ) IS v(l)/ - 

. . . / i ( n) IS v(n) 


This request enables one to enter information about a new 
program into an information file. This request requires 
that information values be provided for each required item/ 
as previously listed/ in the form: 

item name I S/ARE item value 


The NAME of new information items may be defined by typing 
the new item name and its value. When the INFO system 
prints an item name followed by two periods/ the user is to 
type the value of that i tern. I tern names and i tern values of 
other items may be supplied following the item value which 
was requested/ by typing a comma after each item value and 
thus anticipating the required input and reducing on-line 
i nteract i on. 


If the word FILE is specified in the input specification/ a 
file with primary name the same as the program name (if 
specified) and secondary name INFO is read. This file is 
assumed to contain item values for this program where each 
item value is preceded by a line giving the item name 
prefixed by a period and beginning in column one. If the 
primary name of this input file is not the same as the 
program name/ the file name may be specified by typing the 
i tern 


FILE IS file name 


If a file name i s s pec 
specified/ the NAME of 
i nput file. A program 
the presence of two per 
input file may specify 
preceding the documenta 
giving the program NAME 
example/ ..INFO). The 
was done from an input 
type by typ i ng 


ified and a program NAME is not 
the program may be read from the 
NAME is indicated in an input file by 
iods before the program NAME. An 
the documentation of many programs by 
tion of each program with a line 
prefixed by the two periods (for 
priming of the command documentation 
file (with name COMAND INFO) of this 


STORE FILE IS COMAND . 
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5. The EDIT (E) request: 


EDIT NAME IS name 


This request re-creates a BCD f 
from the information in the sys 
to information items using some 
EDIT request requires that the 
The file created contains all i 
items which can be used with th 
value is preceded by a line giv 
a period (e.g. - .PURPOSE) and 
i tern value should begin with a 
the file created is the same as 
secondary name is INFO. 


i 1 e (as a 1 i n 
tern for use i 
CTSS ed i t i ng 
program NAME 
nformation it 
e find r eques 
i ng the i tern 
consequently 
period. The 
the program 


e marked file) 
n mak i ng changes 
procedure. The 
be specified, 
ems except those 
t . Each i tern 
name prefixed by 
no line of an 
primary name of 
name and the 


6* The ALTER (R) request: 

ALTER NAME IS name/ i(l) IS v(l) # 


i ( n ) IS v ( n ) 


al,ows . one to change item values in the 
information documenting a program or to <?tnro C , 

information items. The ALTER request re q u?res ?ha '°?h! 

program name be specified and is used like t e ?Tn 

r r e e q q ue e ”-in T JhaMt R d reqUeS J I™ he* Itor 

request in that it does not require that 
information items be specified. That is 
interaction is different. 


values for a 1 1 
the user-system 


The REMOVE (R) request: 

REMOVE NAME IS name, D IS d, A IS a I 


TEM IS i 


to delete an AUTHOR/ 
appropr i ate list/ or 


DESCRI PTOR/ 
to delete 


or 

the 


This request is used 
ITEM name from the 

documentation of a program from an information f Me wh Pn a 
program ,s deleted from CTSS. To REMOVE the document!? i on 
of a program give the program NAME. To REMOVE an AUTHOR 

DESCRIPTORS^ °< "? 8s °[ a “ESCRIPTOR from the ?isf of* 
UtBLKI PTORS/ specify the item value to be removed 

a program' ?s C C ° rem ° Ve the documentation of 
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SYSTEM REQUESTS 


8. The QUIT (QU) request: 

This request causes the INFO system to call CHNCOM and may 
be used to terminate the INFO command or to chain to other 
commands . 


9. The (no abbreviation) request: 

This request causes the INFO system to terminate through the 
standard COMIT termination sequence. (The INFO command has 
been written in the COMIT language.) The amount of unused 
free storage/ i.e./ the number of WORKSPACE registers/ is 
pr i nted. 


10. The TSSF I L (no abbreviation) request: 

This request causes the INFO files to be obtained from one 
of the CTSS system file directories and is required before 
the INFO system is included as a CTSS command. 


11. The USRF I L (no abbreviation) request: 

This request causes the INFO files to be obtained f r om the 
user's file directory rather than the system file directory. 
This request may be used by a user to indicate that the 
documentation files are to be obtained from the user s 
directory. In this way a user may keep documentation on his 

private programs. 
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Summary of INFO requests 


RETRIEVAL REQUESTS 

1. DESCRIBE NAME IS name/ i(l)...i(n) 

2. LIST i (1) . . . i ( n) , TYPE IS type 

3. FIND i(l) IS v(l), . . . , i(n) IS v(n) 

STORAGE REQUESTS 

4. STORE NAME IS name, FILE IS file, id) IS v(l) 

. . . , i ( n) I S 

5. EDIT NAME IS name 

b. ALTER NAME IS name, i (1) IS v(l), . . . , i( n ) 

7. REMOVE NAME IS name, D I S d, A is a, ITEM |S i 

SYSTEM REQUESTS 

8. END 

9. QUIT 

10. TSSFIL 

11. USRFIL 


Required information items are: 

NAME (N), TYPE (T), DESCRIPTORS (D), PURPOSE (R), 
USAGE (U), LANGUAGE (L), REFERENCE (R), 

AUTHOR (A), and DATE (DA). 


v(n) 

IS v(n) 


Note: 


i stands for item name and v stands for item value. 
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I dent i f i cat i on 

Macro Command 
RUNCOM, CHAIN 

Purpose 

Public and private commands may be linked or chained 
together in order that the chain may be executed by merely 
issuing one command. This is convenient if the same series 
of commands is to be executed more than once and the user 
does not wish to retype the series eachtime. Arguments to 
the commands may be specified at execution time. 

Reference 

Section AG. 8 gives further information about macro command 
programs. 

U?age . 

Command Cha i n : 

The command chain, or macro-command, must first be prepared 
as a BCD line-marked or line-numbered file, with one command 
per line. Blank lines are ignored. Command arguments are 
separated by one or more spaces; if an argument is more than 
six characters long, it will be truncated from the left. 
Arguments may be command names, actual argument values or 
dummy symbols. If dummy symbols are used, there must be a 
list of the dummy symbols specified by the pseudo-command 
CHAIN somewhere before the first executable command. 


Example of a macro-command: 

CHAIN ALPH BET TRANS L 
ED ALPH TRANSL 

PRINTF ALPH TRANSL 
TRANSL ALPH 

LOAD ALPH BET (LI BE) OWNLIB 
etc. 

Comments may be included in the command chain 
as lines which have as the first character an 
or a '$'. Comments introduced by will 

be ignored during execution. Comments 
introduced by '$' will be printed on the 
user's console at the point of execution 
corresponding to their position in the chain. 
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Execution of Command Chain: 

RUNCOM NAME1 ARG1 ARG2 ARGn 

NAME1 is the primary name of the BCD command chain 
f i le NAME1 BCD. 

ARGi are the arguments to be substituted for the 
dummy symbols (if any) in the same order as 
specified in the pseudo-command CHAIN. If any 
ARGi is '(NIL)'/ the corresponding dummy 

argument will be ignored; if it is substituted 
for a command name, the whole command is 
ignored. If any ARGi is '(END)', it will be 
replaced by_a fence (all 7's). Any additional 
arguments will be ignored by commands in which 
this substitution is performed. If (END) is 
substituted as a command name, the chain is 
terminated at this point. If there are fewer 
ARGi. dummy symbols in the CHAIN 

specification, the rightmost dummies will 

retain their literal values. 

RUNCOM will interpret the file NAME1 BCD, substitute 
the explicit arguments for dummy arguments, if 
any,. and perform the execution of the 

specified commands by appropriate use of the 
supervisor command chain buffers and 

subroutines. RUNCOM contains a list of public 
commands indicating whether or not each 

command assumes a current core image; RUNCOM 
can then properly intersperse the SAVE and 
RESUME commands. Nesting and recursion are 
poss i b 1 e. 

Core image management: 

Some more details may be necessary to understand the 
mechanism whereby RUNCOM takes care of core images 
between commands. 

As a general rule, a core image is kept over two 
consecutive commands if, and only if, the first one is 
supposed to leave a core image, and the second one is 
, supposed to expect a core image. 

e. g. LOAD - SAVE - FAPDBG 
Use the same core image created by the LOAD command. 

Whereas LOAD - SAVE - L I STF does not keep the core 
image from SAVE to LISTF. Commands which are supposed 
to leave a core image are: 
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CTEST1 to CTEST9 _ __ ^ 

LOAD VLOAD NCLOAD LOADGO LDABS USE START 
PM TRA STOPAT PATCH 
FAPDBG STRACE L 
SAVE RESUME R RESTOR 
MYSAVE RECALL CONTI N RSTART 
RUNCOM 

Commands which are supposed to expect a core image are. 

PM TRA STOPAT PATCH 
USE START 
SAVE MYSAVE 
FAPDBG STRACE 

(NIL) arguments as command names, and $ headed lines do 
not alter the saving of a core image. 

As one may notice, RUNCOM itself may yield a core 
image, if the last command in the chain does, e.g., 

LOAD ALPHA BETA 
SAVE ZETA 
LISTF ZETA SAVED 
RESTOR ZETA 

i 

J) Q may be used as a macro-command, and followed by a START 

I , command. 

Common file switching: 

The only commands which are allowed to begin and 
terminate in different file directories are: 

COMFIL COPY UPDATE REMARK LOG 

Indeed, COMFIL switches to whatever directory is 
specified, and the others switch to the user s file 
directory when completed. 

Any other command must be initiated and terminated in 
the same file directory. On the other hand, there is 
no restriction on the various switching which may be 
performed during the execution of the commands, as long 
as the initial setting is restored before the end. 

One should notice that the present implementation of 
the common files results in losing the temporary files 
created in the common files, as soon as one switches to 
some other directory. However, temporary files always 
stay in the user's file directory, regardless of the 
\ common files switching. 
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RUNCOM may be initiated in any common file, but the 
RUNCOM command will switch back to its initial file 
directory whenever it needs to load a new set of 
commands for execution. Consequently this may result 
in losing temporary files, if the execution was in a 
different common file. 

It should be noted that a $ headed line produces a 
major break in the RUNCOM command. The following 
commands In the chain will then be loaded together in 
the supervisor's buffers, up to a maximum of 3 at a 
time. This, peculiarity may be used to deal with 
temporary files in the common file directories. 

COMFIL 3 

LISTF ALPHA BETA 
PRINTF ALPHA BETA 
$ EDIT 

EDIT ALPHA BETA 
FILE ALPHA BETA 
BETA ALPHA 


Will Insure that the (EDIT FILE) is not lost 
between EDIT and FILE, because the previous line 
headed by a $ has automatically forced the 

beginning of a new sub-chain in the supervisor's 
buffers . 

Some examples of macro-commands: 

We shall assume here that the name of the BCD file 
containing the chain is MACRO BCD. 

1. CHAIN FILE (NIL) (END) 

ED FILE MAD 

MAD FILE (NIL) 

(END) FILE ... (LIBE) ... 

may be called in the following ways: 

RUNCOM MACRO FILE 
Whence: ED FILE MAD 

MAD FILE 

RUNCOM MACRO FILE (LIST) 

Whence: ED FILE MAD 

MAD FILE (LIST) 

RUNCOM MACRO FILE (SYMB) VLOAD 
Whence: ED FILE MAD 

MAD FILE ( SYMTB ) 

VLOAD FILE ... (LIBE) ... 

2. CHAIN FILE BCD FI LI N1 N2 
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* THIS MACRO INSERTS THE FILE FILE BCD 

* INTO THE FILE FIL1 BCD, AFTER LINE NUMBER N1 

* AND DELETES THE INITIAL PART OF FIL1 BCD 

* UNTI L AFTER N2. 

SPLIT F I LI BCD (A) N1 * N2 (B) 

CHMODE (A) BCD T (B) BCD T 
COMB I N * F I LI BCD (A) FILE (B) 

May be called by : 

RUNCOM MACRO ALPA FAP BETA 1030 1040 

inserts ALPA FAP after line 1030, and deletes 

until after 1040 

RUNCOM MACRO ALFA FAP BETA 1030 1030 

same thing, but does not delete anything from 

BETA FAP 


3 . 


RUNCOM MACRO * FAP BETA 1030 1050 

deletes in BETA FAP lines after 1030 until 

after 1050 


♦THIS CHAIN ALLOWS STACKING COMMANDS TYPED ON THE 
♦CONSOLE, AND THEN STARTS THE EXECUTION 

SPLIT MACRO BCD MACRO N , rvpnlT | n .„ 

♦ N IS THE NUMBER OF THE LINE CONTAINING 'EXECUTION 

EDIT MACRO BCD 
F I LE MACRO BCD 
$ EXECUTION 
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I dent i f i cat i on 

Supply arguments in octal to any command 
GENCOM 

Purpose 

if for some reason, the desired arguments for any command 
cannot be expressed in BCD, the command _ may be used with the 
arguments expressed as pairs of six-digit octal arguments. 

Usage 

GENCOM COMAND 0CT11 0CT21 0CT12 OCT22 . . .OCTln 0CT2n 

COMAND is the BCD name of the desired command. 

OCTli 0CT2 i are pairs of six-digit octal equivalents 
of the desi red arguments for COMAND. GENCOM 
checks to be sure they are octal. 

GENCOM will combine the pairs of six-digit octal 
arguments, OCTli 0CT2i, into single twelve 
digit octal arguments, ARGi,and by the use of 
XECOM will initiate the command. 

COMAND ARG1 ARG2 . . . ARGn 
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